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

5676 lines
446 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',
Pholio - support editing images - fixes T3489 Summary: Nice title. We add three new transactions - IMAGE_FILE, IMAGE_NAME, and IMAGE_DESCRIPTION. The first is a bit like subscribers as it is a list of file phids. The latter have values of the form ($file_phid => $data), where $data is $name or $description respectively. This is because we need to collate transactions based on $file_phid... Overall, this uses the _underyling files_ and not the "PholioImage" to determine if things are unique or not. That said, simply mark PholioImages as obsolete so inline comments about no-longer applicable PholioImages don't break. Does a reasonable job implementing the mock. Note you can't "update" an image at this time, though you can delete and add at will. Test Plan: played with pholio a ton. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3489 Differential Revision: https://secure.phabricator.com/D6441
2013-07-16 22:31:20 +02:00
'AphrontAbstractAttachedFileView' => 'view/control/AphrontAbstractAttachedFileView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontAjaxResponse' => 'aphront/response/AphrontAjaxResponse.php',
Move some aprhont/ stuff around a little bit Summary: "configuration/default" moved to "default". Rename it to "configuration" and put config stuff back there. Put writeguard into writeguard/. Test Plan: tools Reviewers: vrana Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2639
2012-06-01 21:46:28 +02:00
'AphrontApplicationConfiguration' => 'aphront/configuration/AphrontApplicationConfiguration.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontBarView' => 'view/widget/bars/AphrontBarView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'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',
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',
'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',
'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',
Improve accessibility of some UI elements (forms, icons, timeline) Summary: Ref T4843. Chips away at a few more things. Test Plan: Used VoiceOver and got a generally more sensible-seeming result. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4843 Differential Revision: https://secure.phabricator.com/D8978
2014-05-05 17:16:35 +02:00
'AphrontFormSectionControl' => 'view/form/control/AphrontFormSectionControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormSelectControl' => 'view/form/control/AphrontFormSelectControl.php',
'AphrontFormStaticControl' => 'view/form/control/AphrontFormStaticControl.php',
'AphrontFormSubmitControl' => 'view/form/control/AphrontFormSubmitControl.php',
'AphrontFormTextAreaControl' => 'view/form/control/AphrontFormTextAreaControl.php',
'AphrontFormTextControl' => 'view/form/control/AphrontFormTextControl.php',
Clean up the Diffusion search UI a little bit Summary: Ref T156. @vlada recently implemented filename search in Diffusion, this cleans up the UI a little bit: - Instead of showing one search box with two different buttons, let the submit buttons appear to the right of the text boxes and separate the search modes. - Clean up the results a little bit (don't show columns which don't exist). Test Plan: {F107260} Reviewers: vlada, btrahan, chad Reviewed By: chad CC: vlada, chad, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8125
2014-02-01 20:48:28 +01:00
'AphrontFormTextWithSubmitControl' => 'view/form/control/AphrontFormTextWithSubmitControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormToggleButtonsControl' => 'view/form/control/AphrontFormToggleButtonsControl.php',
'AphrontFormTokenizerControl' => 'view/form/control/AphrontFormTokenizerControl.php',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'AphrontFormTypeaheadControl' => 'view/form/control/AphrontFormTypeaheadControl.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontFormView' => 'view/form/AphrontFormView.php',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'view/widget/bars/AphrontGlyphBarView.php',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'aphront/response/AphrontHTMLResponse.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'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',
When stopping on redirect, show a full stack trace Summary: Ref T4140. Provide more debugging information so we can figure out what's going on with redirect loops. Test Plan: {F83868} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4140 Differential Revision: https://secure.phabricator.com/D7620
2013-11-21 23:38:29 +01:00
'AphrontStackTraceView' => 'view/widget/AphrontStackTraceView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTableView' => 'view/control/AphrontTableView.php',
Genericize implementing views which expose common attributes Summary: Some views expose some/most/all of the basics (id, class, sigil, metadata, etc); let them extend a dedicated view to get it for free. Test Plan: Viewed home page, paste, mobile dropdown, etc. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D4440
2013-01-16 19:50:41 +01:00
'AphrontTagView' => 'view/AphrontTagView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'AphrontTokenizerTemplateView' => 'view/control/AphrontTokenizerTemplateView.php',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'AuditActionMenuEventListener' => 'applications/audit/events/AuditActionMenuEventListener.php',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'CalendarColors' => 'applications/calendar/constants/CalendarColors.php',
'CalendarConstants' => 'applications/calendar/constants/CalendarConstants.php',
Fix calendar display on profile. Summary: ...maybe anyway because I can't reproduce it live. This diff does two things that should help with bugginess though - uses $viewer rather than $user (...$user is who we are looking at...) *AND* upgrades a Conpherence util class to Calendar, and said util class has unit tests and came about from fixing a similar bug in Conpherence back in the day. Wrote some comments in the util class because I think it has a tendency to trip people up. These comments are not partciularly good however. Test Plan: viewed user profile - looked good. viewed conpherence - looked good. ran unit tests - they passed. (note I would also like to push this live and verify Chad's profile is fixed on secure.phabricator.com) Reviewers: epriestley, chad Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8341
2014-02-25 22:43:31 +01:00
'CalendarTimeUtil' => 'applications/calendar/util/CalendarTimeUtil.php',
'CalendarTimeUtilTestCase' => 'applications/calendar/__tests__/CalendarTimeUtilTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityManagementMapWorkflow' => 'infrastructure/celerity/management/CelerityManagementMapWorkflow.php',
'CelerityManagementWorkflow' => 'infrastructure/celerity/management/CelerityManagementWorkflow.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',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityPhabricatorResources' => 'infrastructure/celerity/resources/CelerityPhabricatorResources.php',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'CelerityPhysicalResources' => 'infrastructure/celerity/resources/CelerityPhysicalResources.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityResources' => 'infrastructure/celerity/resources/CelerityResources.php',
'CelerityResourcesOnDisk' => 'infrastructure/celerity/resources/CelerityResourcesOnDisk.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_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',
Add differential.getrawdiff to Conduit Test Plan: Confirm the API returns a single flat result with a unified git diff. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, charles Differential Revision: https://secure.phabricator.com/D7199
2013-10-03 02:03:53 +02:00
'ConduitAPI_differential_getrawdiff_Method' => 'applications/differential/conduit/ConduitAPI_differential_getrawdiff_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_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_parsecommitmessage_Method' => 'applications/differential/conduit/ConduitAPI_differential_parsecommitmessage_Method.php',
'ConduitAPI_differential_query_Method' => 'applications/differential/conduit/ConduitAPI_differential_query_Method.php',
Add a differential.getdiffs method Summary: I kind of made a mess of the API doing T2784. I figure just adding this is fine but LMK if you'd prefer something like diffquery got cleaned up more to handle this. Also adds an idx() call as I was getting errors looking at old diffs. Fixes T3823. Test Plan: used the new api via test console - great success. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3823 Differential Revision: https://secure.phabricator.com/D6966
2013-09-17 22:55:41 +02:00
'ConduitAPI_differential_querydiffs_Method' => 'applications/differential/conduit/ConduitAPI_differential_querydiffs_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_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 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',
Add "diffusion.createcomment" conduit endpoint Summary: Adds most of Diffusion's commenting options available in the web UI Mark method as deprecated immediately per @epriestley's request Test Plan: Used the Conduit web console to check: * Lookup by PHID works * Error is raised if commit by PHID is not found * "action" validation works and raises appropriate error * "message" raises error if empty * Actions to raise concern or accept commit work * Method is marked as deprecated from the start Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6923
2013-09-09 23:25:08 +02:00
'ConduitAPI_diffusion_createcomment_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_createcomment_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',
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',
Show additional status information during repository import Summary: Ref T2350. Fixes T2231. - Adds log flags around discovery. - Adds message flags for "needs update". This is basically an out-of-band hint to the daemons that a repository should be pulled sooner than normal. We set the flag when users push a revision, and expose a Conduit method that `arc land` will be able to use. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2350, T2231 Differential Revision: https://secure.phabricator.com/D7467
2013-10-31 23:46:57 +01:00
'ConduitAPI_diffusion_looksoon_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_looksoon_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',
Fix map generation.
2014-01-28 02:26:47 +01:00
'ConduitAPI_diffusion_querycommits_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_querycommits_Method.php',
Basic filename search support for Diffusion Summary: Ref T156. Adds basic filename search support for Diffusion, currently only for Git repositories. This is preliminary, and it's up for discussion: - is the UI in the right place; - what should the search query syntax be (e.g. whether to put `*`s in the beginning and end of it); - how to best approach it for Mercurial and/or SVN; - what's the cleanest result format for `lsquery` (I went for the minimum necessary change to `DiffusionBrowseSearchController`). Test Plan: Browse to a repository in Diffusion, and use both `Search File Names` and `Search File Content`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8093
2014-02-01 17:32:23 +01:00
'ConduitAPI_diffusion_querypaths_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_querypaths_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',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'ConduitAPI_diffusion_resolverefs_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_resolverefs_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 - 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',
Provide a rough, unstable API for reporting coverage into Diffusion Summary: Ref T4994. This stuff works: - You can dump a blob of coverage information into `diffusion.updatecoverage`. This wipes existing coverage information and replaces it. - It shows up when viewing files. - It shows up when viewing commits. This stuff does not work: - When viewing files, the Javascript hover interaction isn't tied in yet. - We always show this information, even if you're behind the commit where it was generated. - You can't do incremental updates. - There's no aggregation at the file (this file has 90% coverage), diff (the changes in this commit are 90% covered), or directory (the code in this directory has 90% coverage) levels yet. - This is probably not the final form of the UI, storage, or API, so you should expect occasional changes over time. I've marked the method as "Unstable" for now. Test Plan: - Ran `save_lint.php` to check for collateral damage; it worked fine. - Ran `save_lint.php` on a new branch to check creation. - Published some fake coverage information. - Viewed an affected commit. - Viewed an affected file. {F151915} {F151916} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley, zeeg Maniphest Tasks: T5044, T4994 Differential Revision: https://secure.phabricator.com/D9022
2014-05-18 01:10:54 +02:00
'ConduitAPI_diffusion_updatecoverage_Method' => 'applications/diffusion/conduit/ConduitAPI_diffusion_updatecoverage_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',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'ConduitAPI_harbormaster_Method' => 'applications/harbormaster/conduit/ConduitAPI_harbormaster_Method.php',
Add a rough `harbormaster.querybuildables` Conduit API method Summary: Ref T4809. I need to sort out some of the "status" stuff we're doing before this is actually useful (there's no sensible "status" value to expose right now) but once that happens `arc` can query this to figure out whether it needs to warn the user about pending/failed builds. Test Plan: Ran query with various different parameters. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8794
2014-04-18 01:00:25 +02:00
'ConduitAPI_harbormaster_querybuildables_Method' => 'applications/harbormaster/conduit/ConduitAPI_harbormaster_querybuildables_Method.php',
Add "harbormaster.querybuilds" Conduit API Summary: Ref T4809. This one is more straightforward. A couple of tweaks: - Remove the WAITING status, since nothing ever sets it and I suspect nothing ever will with the modern way artifacts work (maybe). At a minimum, it's confusing with the new Target status that's also called "WAITING" but means something different. - Consolidate 17 copies of these status names into one method. Test Plan: Ran some queries via Conduit, got reasonable looking results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8795
2014-04-18 01:00:58 +02:00
'ConduitAPI_harbormaster_querybuilds_Method' => 'applications/harbormaster/conduit/ConduitAPI_harbormaster_querybuilds_Method.php',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'ConduitAPI_harbormaster_sendmessage_Method' => 'applications/harbormaster/conduit/ConduitAPI_harbormaster_sendmessage_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_macro_Method' => 'applications/macro/conduit/ConduitAPI_macro_Method.php',
Adding macro create method.
2013-06-08 00:08:34 +02:00
'ConduitAPI_macro_creatememe_Method' => 'applications/macro/conduit/ConduitAPI_macro_creatememe_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_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',
Maniphest - add conduit method to get status information Summary: Ref T4938. `arc close` needs to know about custom statuses and this conduit method is step 1 of letting it know Test Plan: See next diff, which works! Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4938 Differential Revision: https://secure.phabricator.com/D8937
2014-05-02 01:11:39 +02:00
'ConduitAPI_maniphest_querystatuses_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_querystatuses_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_maniphest_update_Method' => 'applications/maniphest/conduit/ConduitAPI_maniphest_update_Method.php',
Nuance - conduit method to create items Summary: pretty simple. did the bare minimum in the editor, etc. to be able to create an item from the conduit console. I put the work in the editor for initializing new values, rather than some initializeNewItem method, mainly because Items don't have policy directly but instead policy will be defined by the queue(s) the item is in. The editor is definitely going to host this work, so it felt like it might be better to do it this way in time...? anyway, easy to make an initializeNew method instead if you want to have that paradigm going all the time. Test Plan: made an item from teh conduit console - success. verified errors for missing data as well Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7879
2014-01-06 20:19:32 +01:00
'ConduitAPI_nuance_Method' => 'applications/nuance/conduit/ConduitAPI_nuance_Method.php',
'ConduitAPI_nuance_createitem_Method' => 'applications/nuance/conduit/ConduitAPI_nuance_createitem_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',
Add phame.queryblog and phame.querypost Conduit calls. Summary: This implements Conduit calls for querying Phame blogs and Phame posts. Test Plan: Made some calls and they seem to generally work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D7478
2013-11-03 00:31:30 +01:00
'ConduitAPI_phame_Method' => 'applications/phame/conduit/ConduitAPI_phame_Method.php',
Phame - create conduit API to create posts Summary: nothing too crazy here. try to be smart about some defaults (i.e. phame title is optional and can be derived from title; post as not a draft by default; etc). Fixes T3695. also do a little re-factoring to centralizing initializing new posts and turning posts into dictionaries. also change blogs => posts in another conduit method so it makes sense and stuff. Test Plan: made some posts via conduit. testing trying to specify blogger, phame title, and isDraft, all worked nicely Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D8485
2014-03-11 23:51:53 +01:00
'ConduitAPI_phame_createpost_Method' => 'applications/phame/conduit/ConduitAPI_phame_createpost_Method.php',
Add phame.queryblog and phame.querypost Conduit calls. Summary: This implements Conduit calls for querying Phame blogs and Phame posts. Test Plan: Made some calls and they seem to generally work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D7478
2013-11-03 00:31:30 +01:00
'ConduitAPI_phame_query_Method' => 'applications/phame/conduit/ConduitAPI_phame_query_Method.php',
'ConduitAPI_phame_queryposts_Method' => 'applications/phame/conduit/ConduitAPI_phame_queryposts_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',
Provide `phragment.getstate` and `phragment.getpatch` Conduit methods Summary: This provides a `phragment.getstate` and a `phragment.getpatch` Conduit method. `phragment.getstate` - This returns the current state of the fragment and all of it's children. `phragment.getpatch` - This accepts a base path and a mapping of paths to hashes. The mapping is for the caller to specify the current state of the files it has. This returns a list of patches that the caller needs to apply to it's files to get to the latest version. Test Plan: Ran the following script in a folder which had content matching a fragment and it's children: ``` #!/bin/bash STATE="" for i in $(find ./ -type f); do HASH=$(cat $i | sha1sum | awk '{ print $1 }') BASE=${i:2} STATE="$STATE,\"$BASE\":\"$HASH\"" done STATE=${STATE:1} STATE="{$STATE}" echo '{"path":"tychaia3.zip","state":'$STATE'}' | arc --conduit-uri=http://phabricator.local/ call-conduit phragment.getpatch ``` and I got: ``` {"error":null,"errorMessage":null,"response":[]} ``` I updated one of the child fragments with a new file and ran the script again (patch has been omitted due to it's size): ``` {"error":null,"errorMessage":null,"response":[{"path":"Content\/TitleFont.xnb","hash_old":"4a927d7b90582e50cdd330de9f4b59b0cc5eb5c7","hash_new":"25867504642a3a403102274c68fbb9b430c1980f","patch":"..."}]} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, staticshock Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7739
2013-12-11 01:19:23 +01:00
'ConduitAPI_phragment_Method' => 'applications/phragment/conduit/ConduitAPI_phragment_Method.php',
'ConduitAPI_phragment_getpatch_Method' => 'applications/phragment/conduit/ConduitAPI_phragment_getpatch_Method.php',
'ConduitAPI_phragment_queryfragments_Method' => 'applications/phragment/conduit/ConduitAPI_phragment_queryfragments_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_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 modern releeph.queryproducts and releeph.querybranches Summary: Ref T3662. Ref T3549. These methods are pretty conservative for now, but get the structure in place. Also do a bunch more project -> product stuff. Test Plan: Made calls to both methods, browsed around the UI a fair amount. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549, T3662 Differential Revision: https://secure.phabricator.com/D8816
2014-04-20 20:54:22 +02:00
'ConduitAPI_releeph_querybranches_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_querybranches_Method.php',
'ConduitAPI_releeph_queryproducts_Method' => 'applications/releeph/conduit/ConduitAPI_releeph_queryproducts_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_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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitConnectionGarbageCollector' => 'applications/conduit/garbagecollector/ConduitConnectionGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitLogGarbageCollector' => 'applications/conduit/garbagecollector/ConduitLogGarbageCollector.php',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ConpherenceActionMenuEventListener' => 'applications/conpherence/events/ConpherenceActionMenuEventListener.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',
Conpherence - add dropdown menu Summary: Fixes T3641. Probably needs some @chad love though on colors and what have you. Technique was to jam this into the existing notifications stuff as much as possible. I think its "okay" but if we were to add more stuff here (like a 3rd application) this could get a quality pass to consolidate even more code. Test Plan: played with it in Chrome and Safari - looks reasonable Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3641 Differential Revision: https://secure.phabricator.com/D6708
2013-08-08 22:43:33 +02:00
'ConpherenceNotificationPanelController' => 'applications/conpherence/controller/ConpherenceNotificationPanelController.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipant' => 'applications/conpherence/storage/ConpherenceParticipant.php',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'applications/conpherence/query/ConpherenceParticipantCountQuery.php',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'applications/conpherence/query/ConpherenceParticipantQuery.php',
'ConpherenceParticipationStatus' => 'applications/conpherence/constants/ConpherenceParticipationStatus.php',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'applications/conpherence/view/ConpherencePeopleWidgetView.php',
Conpherence - 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',
'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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'DifferentialActionMenuEventListener' => 'applications/differential/event/DifferentialActionMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialAddCommentView' => 'applications/differential/view/DifferentialAddCommentView.php',
'DifferentialAffectedPath' => 'applications/differential/storage/DifferentialAffectedPath.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialApplyPatchField' => 'applications/differential/customfield/DifferentialApplyPatchField.php',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialArcanistProjectField' => 'applications/differential/customfield/DifferentialArcanistProjectField.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAsanaRepresentationField' => 'applications/differential/customfield/DifferentialAsanaRepresentationField.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialAuditorsField' => 'applications/differential/customfield/DifferentialAuditorsField.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAuthorField' => 'applications/differential/customfield/DifferentialAuthorField.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialBlameRevisionField' => 'applications/differential/customfield/DifferentialBlameRevisionField.php',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialBranchField' => 'applications/differential/customfield/DifferentialBranchField.php',
Add a "default view" policy to Differential Summary: Ref T603. Allows the Differential view policy to be configured with a default. I've omitted "edit" because I want to wait and see how comment/comment-action policies work out. I could imagine locking "edit" down to only the owner at some point, and providing a wider "interact" capability, or something like that, which would cover accept/reject/commandeer. Users in this group could still edit indirectly by commandeering first. Test Plan: Created new revisions from the CLI and conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7269
2013-10-09 22:58:00 +02:00
'DifferentialCapabilityDefaultView' => 'applications/differential/capability/DifferentialCapabilityDefaultView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangeType' => 'applications/differential/constants/DifferentialChangeType.php',
Restore "Branch" and "changes since last update" fields to Differential mail Summary: Ref T418. Fixes T4642. The "changes since last update" and "branch" fields got dropped; restore them in a general, field-driven way. Test Plan: - Created a revision, got relevant sections in mail. - Commented on a revision, got relevant sections in mail. - Updated a revision, got relevant sections in mail. Reviewers: btrahan Reviewed By: btrahan Subscribers: spicyj, epriestley Maniphest Tasks: T418, T4642 Differential Revision: https://secure.phabricator.com/D8657
2014-04-01 17:23:34 +02:00
'DifferentialChangesSinceLastUpdateField' => 'applications/differential/customfield/DifferentialChangesSinceLastUpdateField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangeset' => 'applications/differential/storage/DifferentialChangeset.php',
'DifferentialChangesetDetailView' => 'applications/differential/view/DifferentialChangesetDetailView.php',
upgrade diffusion to use modern header UI and fix a few quirks Summary: upgrades are CrumbsView, HeaderView, PropertyListView, and ActionListView. I had to modify CrumbsView stuff a bit to handle the "advanced" diffusion crumbs. Quirks fixed include making file tree view show up in diffusion, the page not have extra space when the file tree is hidden, links no longer breaking once you visit files (since without the change the files always got "/" appended and thus 404'd), and a differential quirk where it read "next step:" and that colon is a no no, Test Plan: played around in diffusion and differential Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad Maniphest Tasks: T2048, T2178 Differential Revision: https://secure.phabricator.com/D4169
2012-12-13 02:50:42 +01:00
'DifferentialChangesetFileTreeSideNavBuilder' => 'applications/differential/view/DifferentialChangesetFileTreeSideNavBuilder.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetHTMLRenderer' => 'applications/differential/render/DifferentialChangesetHTMLRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetListView' => 'applications/differential/view/DifferentialChangesetListView.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetOneUpRenderer' => 'applications/differential/render/DifferentialChangesetOneUpRenderer.php',
'DifferentialChangesetOneUpTestRenderer' => 'applications/differential/render/DifferentialChangesetOneUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetParser' => 'applications/differential/parser/DifferentialChangesetParser.php',
Unhighlight lines modified in rebase Summary: Diff of diffs display changes between new versions of file. This is bad after rebase because there can be many unrelated changes so it is hard to spot the real change. This diff unhighlights the lines that were added or removed in rebase. The changes are still visible (they can be sometimes relevant) but very subtle. Test Plan: # Add, change and delete line. Display diff. # Add and change some lines in parent. Rebase. Display diff. Display diff of diff. # Change and add some lines. Display diff. Display diff to first diff. Display diff to second diff. Reviewers: epriestley, jungejason Reviewed By: jungejason CC: jungejason, aran, Korvin Differential Revision: https://secure.phabricator.com/D2761
2012-06-15 09:53:26 +02:00
'DifferentialChangesetParserTestCase' => 'applications/differential/parser/__tests__/DifferentialChangesetParserTestCase.php',
Introduce DifferentialChangesetQuery and remove loadHunks() Summary: Ref T4045. Ref T5179. This removes all non-Query hunk loads. Test Plan: - Viewed revisions. - Viewed standalone changesets. - Viewed raw old/new files. - Viewed vs diffs. - Enabled inline comments in mail and sent some transactions with inlines. - Called `differential.getrawdiff`. - Grepped for `loadHunks()`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9289
2014-05-25 17:59:31 +02:00
'DifferentialChangesetQuery' => 'applications/differential/query/DifferentialChangesetQuery.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetRenderer' => 'applications/differential/render/DifferentialChangesetRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTestRenderer' => 'applications/differential/render/DifferentialChangesetTestRenderer.php',
Refactor DifferentialChangesetParser -- pass 1 of N Summary: basically did my darnedest to pull out a TwoUp rendering view. Made a base class for the rendering views with "old" and "new" terminology rather than "left" and "right. Future revisions will finish cleaning up the terminology within the DifferentialChangesetParser itself and more of the ideas within T2009. Test Plan: been playing with differential all day Reviewers: epriestley Reviewed By: epriestley CC: vrana, chad, aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4117
2012-12-08 01:19:57 +01:00
'DifferentialChangesetTwoUpRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpRenderer.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTwoUpTestRenderer' => 'applications/differential/render/DifferentialChangesetTwoUpTestRenderer.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialChangesetViewController' => 'applications/differential/controller/DifferentialChangesetViewController.php',
'DifferentialCommentPreviewController' => 'applications/differential/controller/DifferentialCommentPreviewController.php',
'DifferentialCommentSaveController' => 'applications/differential/controller/DifferentialCommentSaveController.php',
Move Differential commit message parsing to a separate, tested class Summary: Ref T2222. We have a hunk of logic that purely does text parsing here; separate it and get coverage on it. Test Plan: - Ran new unit tests. - Used `differential.parsecommitmessage`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8444
2014-03-08 02:44:35 +01:00
'DifferentialCommitMessageParser' => 'applications/differential/parser/DifferentialCommitMessageParser.php',
'DifferentialCommitMessageParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCommitMessageParserTestCase.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialCommitsField' => 'applications/differential/customfield/DifferentialCommitsField.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialConflictsField' => 'applications/differential/customfield/DifferentialConflictsField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialController' => 'applications/differential/controller/DifferentialController.php',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialCoreCustomField' => 'applications/differential/customfield/DifferentialCoreCustomField.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialCustomField' => 'applications/differential/customfield/DifferentialCustomField.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialCustomFieldDependsOnParser' => 'applications/differential/parser/DifferentialCustomFieldDependsOnParser.php',
'DifferentialCustomFieldDependsOnParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCustomFieldDependsOnParserTestCase.php',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldNumericIndex' => 'applications/differential/storage/DifferentialCustomFieldNumericIndex.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialCustomFieldRevertsParser' => 'applications/differential/parser/DifferentialCustomFieldRevertsParser.php',
'DifferentialCustomFieldRevertsParserTestCase' => 'applications/differential/parser/__tests__/DifferentialCustomFieldRevertsParserTestCase.php',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldStorage' => 'applications/differential/storage/DifferentialCustomFieldStorage.php',
'DifferentialCustomFieldStringIndex' => 'applications/differential/storage/DifferentialCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDAO' => 'applications/differential/storage/DifferentialDAO.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialDependenciesField' => 'applications/differential/customfield/DifferentialDependenciesField.php',
'DifferentialDependsOnField' => 'applications/differential/customfield/DifferentialDependsOnField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialDiff' => 'applications/differential/storage/DifferentialDiff.php',
'DifferentialDiffCreateController' => 'applications/differential/controller/DifferentialDiffCreateController.php',
'DifferentialDiffProperty' => 'applications/differential/storage/DifferentialDiffProperty.php',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
'DifferentialDiffQuery' => 'applications/differential/query/DifferentialDiffQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DifferentialDoorkeeperRevisionFeedStoryPublisher' => 'applications/differential/doorkeeper/DifferentialDoorkeeperRevisionFeedStoryPublisher.php',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'DifferentialDraft' => 'applications/differential/storage/DifferentialDraft.php',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialEditPolicyField' => 'applications/differential/customfield/DifferentialEditPolicyField.php',
Clean up various pieces of dead/obsolete Differential code Summary: Ref T2222. - Removes `DifferentialTasksAttacher`, which has had no callsites for a very long time. - Moves `differential.getrevisioncomments` off `DifferentialCommentQuery`. - Moves Releeph churn field off `DifferentialCommentQuery`. - Removes dead code in `DifferentialRevisionViewController`. - Removes `DifferentialException` (no references). - Removes `DifferentialRevision->loadComments()` (no callsites). - Removes `DifferentialRevision->loadReviewedBy()` (all callsites updated). - Removes `DifferentialCommentQuery` (all callsites updated). Test Plan: Mostly a lot of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8476
2014-03-09 21:44:54 +01:00
'DifferentialFieldParseException' => 'applications/differential/exception/DifferentialFieldParseException.php',
'DifferentialFieldValidationException' => 'applications/differential/exception/DifferentialFieldValidationException.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialGetWorkingCopy' => 'applications/differential/DifferentialGetWorkingCopy.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialGitSVNIDField' => 'applications/differential/customfield/DifferentialGitSVNIDField.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialHostField' => 'applications/differential/customfield/DifferentialHostField.php',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'DifferentialHovercardEventListener' => 'applications/differential/event/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',
Add an alternate "modern" hunk datastore Summary: Ref T4045. Ref T5179. Hunk storage has two major issues: - It's utf8, but actual diffs are binary. - It's huge and can't be compressed or archived. This introduces a second datastore which solves these problems: by recording hunk encoding, supporting compression, and supporting alternate storage. There's no actual compression or storage support yet, but there's space in the table for them. Since nothing actually uses hunk IDs, it's fine to have these tables exist at the same time and use the same IDs. We can migrate data between the tables gradually without requiring downtime or disrupting installs. Test Plan: - There are no writes to the new table yet. - The only effect this has is making us issue one extra query when looking for hunks. - Observed the query issue, but everything else continue working fine. - Created a new diff. - Ran unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9290
2014-05-25 18:28:11 +02:00
'DifferentialHunkLegacy' => 'applications/differential/storage/DifferentialHunkLegacy.php',
'DifferentialHunkModern' => 'applications/differential/storage/DifferentialHunkModern.php',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParser' => 'applications/differential/parser/DifferentialHunkParser.php',
'DifferentialHunkParserTestCase' => 'applications/differential/parser/__tests__/DifferentialHunkParserTestCase.php',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
'DifferentialHunkQuery' => 'applications/differential/query/DifferentialHunkQuery.php',
Simplify DifferentialHunk::getAddedLines() Summary: I will also need `getRemovedLines()` so refactor this first. Test Plan: New test case. Viewed uncached diff. Verified that the only callsite of `getAddedLines()` trims lines. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D2875
2012-06-27 19:44:29 +02:00
'DifferentialHunkTestCase' => 'applications/differential/storage/__tests__/DifferentialHunkTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialInlineComment' => 'applications/differential/storage/DifferentialInlineComment.php',
'DifferentialInlineCommentEditController' => 'applications/differential/controller/DifferentialInlineCommentEditController.php',
'DifferentialInlineCommentEditView' => 'applications/differential/view/DifferentialInlineCommentEditView.php',
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/DifferentialInlineCommentPreviewController.php',
Abstract access to DifferentialInlineComment behind a Query Summary: Ref T2222. See D6260. Push all this junk behind a Query so I can move the storage out from underneath it. Test Plan: Viewed home page, list view, revision. Made draft, looked at preview, submitted draft, viewed inline, replied to inline. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6262
2013-06-21 21:54:56 +02:00
'DifferentialInlineCommentQuery' => 'applications/differential/query/DifferentialInlineCommentQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialInlineCommentView' => 'applications/differential/view/DifferentialInlineCommentView.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialJIRAIssuesField' => 'applications/differential/customfield/DifferentialJIRAIssuesField.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingActionMenuEventListener' => 'applications/differential/landing/DifferentialLandingActionMenuEventListener.php',
'DifferentialLandingStrategy' => 'applications/differential/landing/DifferentialLandingStrategy.php',
Land to GitHub + support stuff Summary: A usable, Land to GitHub flow. Still to do: - Refactor all git/hg stratagies to a sane structure. - Make the dialogs Workflow + explain why it's disabled. - Show button and request Link Account if GH is enabled, but user is not linked. - After refreshing token, user ends up in the settings stage. Hacked something in LandController to be able to show an arbitrary dialog from a strategy. It's not very nice, but I want to make some more refactoring to the controller/strategy/ies anyway. Also made PhabricatorRepository::getRemoteURIObject() public, because it was very useful in getting the domain and path for the repo. Test Plan: Went through these flows: - load revision in hosted, github-backed, non-github backed repos to see button as needed. - hit land with weak token - sent to refresh it with the extra scope. - Land to repo I'm not allowed - got proper error message. - Successfully landed; Failed to apply patch. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7555
2013-11-14 02:25:14 +01:00
'DifferentialLandingToGitHub' => 'applications/differential/landing/DifferentialLandingToGitHub.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingToHostedGit' => 'applications/differential/landing/DifferentialLandingToHostedGit.php',
Add support for landing to hosted Mercurial repos. Summary: I've kept this as close as possible to the Git version for ease of review and later refactoring of them both together. At minimum, the functions to get the working dir should probably be cleaned up one day. Test Plan: Landed a revision. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7534
2013-11-08 20:37:57 +01:00
'DifferentialLandingToHostedMercurial' => 'applications/differential/landing/DifferentialLandingToHostedMercurial.php',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialLintField' => 'applications/differential/customfield/DifferentialLintField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialLintStatus' => 'applications/differential/constants/DifferentialLintStatus.php',
'DifferentialLocalCommitsView' => 'applications/differential/view/DifferentialLocalCommitsView.php',
'DifferentialMail' => 'applications/differential/mail/DifferentialMail.php',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialManiphestTasksField' => 'applications/differential/customfield/DifferentialManiphestTasksField.php',
Assign PHIDs to all diffs Summary: Ref T1049. Ref T2222. `DifferentialDiff` does not currently have a PHID, but we need it for Harbormaster and ApplicationTransactions. See some discussion in D7501. (I split the SQL into two sections so we can't fail in the middle. At some point, I'd like to do a pass on the migration stuff and get this happening automatically, and also simplify the PatchList.) Test Plan: - Ran `bin/storage upgrade`. - Checked for valid PHIDs in the database. - Used `phid.query` to look up a diff by PHID. - Created a new diff and verified it got a PHID. Reviewers: btrahan, hach-que Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2222, T1049 Differential Revision: https://secure.phabricator.com/D7513
2013-11-06 22:59:06 +01:00
'DifferentialPHIDTypeDiff' => 'applications/differential/phid/DifferentialPHIDTypeDiff.php',
Move DifferentialRevision to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.lookup` and `phid.query` to load handles. Grepped for `PHID_TYPE_DREV`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6509
2013-07-21 17:11:37 +02:00
'DifferentialPHIDTypeRevision' => 'applications/differential/phid/DifferentialPHIDTypeRevision.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'DifferentialParseCacheGarbageCollector' => 'applications/differential/garbagecollector/DifferentialParseCacheGarbageCollector.php',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'applications/differential/__tests__/DifferentialParseRenderTestCase.php',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialPathField' => 'applications/differential/customfield/DifferentialPathField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialProjectReviewersField' => 'applications/differential/customfield/DifferentialProjectReviewersField.php',
Abstract raw diff rendering into DifferentialRawDiffRenderer Test Plan: Enable inline patches: ``` bin/config set metamta.differential.patch-format 'unified' bin/config set metamta.differential.inline-patches 100000000 ``` Create a new diff and confirm it renders correctly via email. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7198
2013-10-03 01:28:03 +02:00
'DifferentialRawDiffRenderer' => 'applications/differential/render/DifferentialRawDiffRenderer.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'DifferentialReleephRequestFieldSpecification' => 'applications/releeph/differential/DifferentialReleephRequestFieldSpecification.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'DifferentialRemarkupRule' => 'applications/differential/remarkup/DifferentialRemarkupRule.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialReplyHandler' => 'applications/differential/mail/DifferentialReplyHandler.php',
Implement "Repository" as a new-style CustomField in Differential Summary: Ref T3886. Ref T418. - Adds new capabilities for CustomField: - Controls can now bulk-load PHIDs (e.g., for tokenizers). - Transactions can now bulk-load PHIDs (e.g., for relationship changes). - Implements "Repository" control. - Improves tokenizer StandardCustomField controls. Test Plan: {F115942} {F115943} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8286
2014-02-21 20:53:37 +01:00
'DifferentialRepositoryField' => 'applications/differential/customfield/DifferentialRepositoryField.php',
When creating or updating a revision, infer the repository from the diff Summary: Ref T603. When a diff is attached to a revision, try to guess the repository if possible. In cases where we succeed, this automatically gives us intuitive policy behavior (i.e., you can see a revision if you can see the repository the change is against). I pulled this into a funky little "Lookup" class for two reasons: - It's used in two places; - I anticipate that we might need to add some sort of `explainWhy()` method if users find the heuristics confusing. Test Plan: Created and updated revisions, saw them pick up the correct repository association. Ran Herald dry run against associable and nonassociable revisions, saw correct values populate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7147
2013-09-27 00:28:42 +02:00
'DifferentialRepositoryLookup' => 'applications/differential/query/DifferentialRepositoryLookup.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialRevertPlanField' => 'applications/differential/customfield/DifferentialRevertPlanField.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialReviewedByField' => 'applications/differential/customfield/DifferentialReviewedByField.php',
Methods for reading reviewers from edges in differential Summary: Add `getReviewerStatus` to get an array of `DifferentialReviewer` objects. The method `needReviewerStatus` in `DifferentialRevisionQuery` loads the edges into the revisions loaded. Test Plan: Added `->needReviewerStatus(true)` to `DifferentialRevisionSearchEngine` and checked through logging that the data was being loaded correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6450
2013-07-15 04:18:55 +02:00
'DifferentialReviewer' => 'applications/differential/storage/DifferentialReviewer.php',
Store revision reviewer state as edges Summary: Keep track of the state of a reviewer in an edge between reviewer and revision. The edge stores the state of the review, added or rejected. And if the revision was accepted by that reviewer the id of the diff accepted. Test Plan: Create diffs and clowncopterize reviewer list changes. This includes: * Adding new reviewers * Resigning * Commandering a revision Reviewers: epriestley CC: aran, Korvin Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D6372 Conflicts: src/applications/differential/editor/DifferentialCommentEditor.php
2013-07-10 22:45:14 +02:00
'DifferentialReviewerStatus' => 'applications/differential/constants/DifferentialReviewerStatus.php',
Implement a "Reviewers" CustomField Summary: Ref T3886: - Adds a "Reviewers" field as a modern CustomField. Ref T418: - Allows CustomFields to emit transaction metadata. Test Plan: {F116254} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8291
2014-02-21 20:54:32 +01:00
'DifferentialReviewersField' => 'applications/differential/customfield/DifferentialReviewersField.php',
Split users apart from projects/packages in reviewer and audit UIs Summary: Ref T1279. Show separate sections for "Reviewers" and "Project Reviewers" (Differential) and for "Auditors" and "Package/Project Auditors" (Diffusion/Audit). Test Plan: - Looked at a commit. Saw separation. - Looked at a revision. Saw separation. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7233
2013-10-05 16:54:42 +02:00
'DifferentialReviewersView' => 'applications/differential/view/DifferentialReviewersView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevision' => 'applications/differential/storage/DifferentialRevision.php',
'DifferentialRevisionControlSystem' => 'applications/differential/constants/DifferentialRevisionControlSystem.php',
'DifferentialRevisionDetailView' => 'applications/differential/view/DifferentialRevisionDetailView.php',
'DifferentialRevisionEditController' => 'applications/differential/controller/DifferentialRevisionEditController.php',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialRevisionIDField' => 'applications/differential/customfield/DifferentialRevisionIDField.php',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialRevisionLandController' => 'applications/differential/controller/DifferentialRevisionLandController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionListController' => 'applications/differential/controller/DifferentialRevisionListController.php',
'DifferentialRevisionListView' => 'applications/differential/view/DifferentialRevisionListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'applications/differential/mail/DifferentialRevisionMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
'DifferentialRevisionSearchEngine' => 'applications/differential/query/DifferentialRevisionSearchEngine.php',
change DifferentialRevisionDetailView to use newer fangled UI abstractions Summary: actions are still a bit messy - unsatisfactory icons (T2013 will help!) Test Plan: viewed diffs - they look good Reviewers: epriestley, vrana Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T2007 Differential Revision: https://secure.phabricator.com/D3904
2012-12-11 23:59:27 +01:00
'DifferentialRevisionStatus' => 'applications/differential/constants/DifferentialRevisionStatus.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/DifferentialRevisionUpdateHistoryView.php',
'DifferentialRevisionViewController' => 'applications/differential/controller/DifferentialRevisionViewController.php',
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',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialStoredCustomField' => 'applications/differential/customfield/DifferentialStoredCustomField.php',
Implement Differential subscribers as a CustomField Summary: Ref T3886. Now that a custom field can emit a core transaction, just emit a subscribers transaction. Test Plan: {F116014} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8289
2014-02-21 20:54:08 +01:00
'DifferentialSubscribersField' => 'applications/differential/customfield/DifferentialSubscribersField.php',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialSummaryField' => 'applications/differential/customfield/DifferentialSummaryField.php',
Implement "Test Plan" as a CustomField Summary: Ref T3886. Moves some of the "required" logic to the base class ("DifferentialCoreField") so Title and Test Plan can share it. Test Plan: Edited revisions using "pro" editor, saw test plan transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8285
2014-02-21 20:53:27 +01:00
'DifferentialTestPlanField' => 'applications/differential/customfield/DifferentialTestPlanField.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTitleField' => 'applications/differential/customfield/DifferentialTitleField.php',
Add storage for new Differential transactions and transaction comments Summary: Ref T2222. Ref T1460. Depends on D6260. This creates the new tables, but doesn't start using them. I added three new fields for {T1460}, to represent fixed/done/replied states. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1460, T2222 Differential Revision: https://secure.phabricator.com/D6261
2013-06-21 21:54:29 +02:00
'DifferentialTransaction' => 'applications/differential/storage/DifferentialTransaction.php',
'DifferentialTransactionComment' => 'applications/differential/storage/DifferentialTransactionComment.php',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTransactionEditor' => 'applications/differential/editor/DifferentialTransactionEditor.php',
Migrate Differential comments to ApplicationTransactions Summary: Ref T2222. This is the big one. This migrates each `DifferentialComment` to one or more ApplicationTransactions (action, cc, reviewers, update, comment, inlines), and makes `DifferentialComment` a double-reader for ApplicationTransactions. The migration is pretty straightforward: - If a comment took an action not otherwise covered, it gets an "action" transaction. This is something like "epriestley abandoned this revision.". - If a comment updated the diff, it gets an "updated diff" transaction. Very old transactions of this type may not have a diff ID (probably only at Facebook). - If a comment added or removed reviewers, it gets a "changed reviewers" transaction. - If a comment added CCs, it gets a "subscribers" transaction. - If a comment added comment text, it gets a "comment" transaction. - For each inline attached to a comment, we generate an "inline" transaction. Most comments generate a small number of transactions, but a few generate a significant number. At HEAD, the code is basically already doing this, so comments in the last day or two already obey these rules, roughly, and will all generate only one transaction (except inlines). Because we've already preallocated PHIDs in the comment text table, we only need to write to the transaction table. NOTE: This significantly degrades Differential, making inline comments pretty much useless (they each get their own transaction, and don't show line numbers or files). The data is all fine, but the UI is garbage now. This needs to be fixed before we can deploy this to users, but it's easily separable since it's all just display code. Specifically, they look like this: {F112270} Test Plan: I've migrated locally and put things through their paces, but it's hard to catch sketchy stuff locally because most of my test data is nonsense and bad migrations wouldn't necessarily look out of place. IMPORTANT: I'm planning to push this to a branch and then shift production over to the branch, and run it for a day or two before bringing it to master. I generally feel good about this change: it's not that big since we were able to separate a lot of pieces out of it, and it's pretty straightforward. That said, it's still one of the most scary/dangerous changes we've ever made. Reviewers: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8210
2014-02-12 00:36:58 +01:00
'DifferentialTransactionQuery' => 'applications/differential/query/DifferentialTransactionQuery.php',
Use timeline view in Differential and make inlines somewhat usable again Summary: Ref T2222. This gets rid of Differential's custom view and uses a standard view instead. This also mostly fixes the rendering logic for inlines. This is headed to the `tmp.differential` branch. Test Plan: {F112696} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1790, T2222 Differential Revision: https://secure.phabricator.com/D8215
2014-02-12 23:05:40 +01:00
'DifferentialTransactionView' => 'applications/differential/view/DifferentialTransactionView.php',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialUnitField' => 'applications/differential/customfield/DifferentialUnitField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DifferentialUnitStatus' => 'applications/differential/constants/DifferentialUnitStatus.php',
'DifferentialUnitTestResult' => 'applications/differential/constants/DifferentialUnitTestResult.php',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialViewPolicyField' => 'applications/differential/customfield/DifferentialViewPolicyField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionBranchTableController' => 'applications/diffusion/controller/DiffusionBranchTableController.php',
'DiffusionBranchTableView' => 'applications/diffusion/view/DiffusionBranchTableView.php',
'DiffusionBrowseController' => 'applications/diffusion/controller/DiffusionBrowseController.php',
Improve organization of Diffusion browse controllers Summary: Currently we have this: - DiffusionController (abstract, has some random shared browse code) - DiffusionBrowseController (concrete, Handles routing, directories, and search) - DiffusionBrowseFileController (concrete, handles files) Instead, do this: - DiffusionController (no browse-related code) - DiffusionBrowseController (abstract, shared browse code) - DiffusionBrowseMainController (concrete, handles routing) - DiffusionBrowseDirectoryController (concrete, handles directories) - DiffusionBrowseFileController (concrete, handles files) - DiffusionBrowseSearchController (concrete, handles search) Feels a lot cleaner. Test Plan: Looked at directories, searches, and files. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7045
2013-09-20 01:01:34 +02:00
'DiffusionBrowseDirectoryController' => 'applications/diffusion/controller/DiffusionBrowseDirectoryController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionBrowseFileController' => 'applications/diffusion/controller/DiffusionBrowseFileController.php',
Improve organization of Diffusion browse controllers Summary: Currently we have this: - DiffusionController (abstract, has some random shared browse code) - DiffusionBrowseController (concrete, Handles routing, directories, and search) - DiffusionBrowseFileController (concrete, handles files) Instead, do this: - DiffusionController (no browse-related code) - DiffusionBrowseController (abstract, shared browse code) - DiffusionBrowseMainController (concrete, handles routing) - DiffusionBrowseDirectoryController (concrete, handles directories) - DiffusionBrowseFileController (concrete, handles files) - DiffusionBrowseSearchController (concrete, handles search) Feels a lot cleaner. Test Plan: Looked at directories, searches, and files. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7045
2013-09-20 01:01:34 +02:00
'DiffusionBrowseMainController' => 'applications/diffusion/controller/DiffusionBrowseMainController.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',
Improve organization of Diffusion browse controllers Summary: Currently we have this: - DiffusionController (abstract, has some random shared browse code) - DiffusionBrowseController (concrete, Handles routing, directories, and search) - DiffusionBrowseFileController (concrete, handles files) Instead, do this: - DiffusionController (no browse-related code) - DiffusionBrowseController (abstract, shared browse code) - DiffusionBrowseMainController (concrete, handles routing) - DiffusionBrowseDirectoryController (concrete, handles directories) - DiffusionBrowseFileController (concrete, handles files) - DiffusionBrowseSearchController (concrete, handles search) Feels a lot cleaner. Test Plan: Looked at directories, searches, and files. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7045
2013-09-20 01:01:34 +02:00
'DiffusionBrowseSearchController' => 'applications/diffusion/controller/DiffusionBrowseSearchController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Activate the new Repository creation workflow Summary: Ref T2231. This: - Activates the new multi-step workflow, and exposes it in the UI. - Adds "can create", "default view" and "default edit" capabilities. - Provides a default value for `repository.default-local-path` and forces repositories into it by default. It's still editable, but Phabricator gets it correct (for some definition of correct) by default now. Test Plan: Created some new repositories with the new workflow. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7413
2013-10-26 02:46:08 +02:00
'DiffusionCapabilityCreateRepositories' => 'applications/diffusion/capability/DiffusionCapabilityCreateRepositories.php',
'DiffusionCapabilityDefaultEdit' => 'applications/diffusion/capability/DiffusionCapabilityDefaultEdit.php',
Add global "push" policy to Repositories Summary: No editing or view yet, just adds the schema and a policy default. Part of D7391. Test Plan: `bin/storage upgrade` Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7415
2013-10-26 04:12:52 +02:00
'DiffusionCapabilityDefaultPush' => 'applications/diffusion/capability/DiffusionCapabilityDefaultPush.php',
Activate the new Repository creation workflow Summary: Ref T2231. This: - Activates the new multi-step workflow, and exposes it in the UI. - Adds "can create", "default view" and "default edit" capabilities. - Provides a default value for `repository.default-local-path` and forces repositories into it by default. It's still editable, but Phabricator gets it correct (for some definition of correct) by default now. Test Plan: Created some new repositories with the new workflow. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7413
2013-10-26 02:46:08 +02:00
'DiffusionCapabilityDefaultView' => 'applications/diffusion/capability/DiffusionCapabilityDefaultView.php',
Add global "push" policy to Repositories Summary: No editing or view yet, just adds the schema and a policy default. Part of D7391. Test Plan: `bin/storage upgrade` Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7415
2013-10-26 04:12:52 +02:00
'DiffusionCapabilityPush' => 'applications/diffusion/capability/DiffusionCapabilityPush.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionChangeController' => 'applications/diffusion/controller/DiffusionChangeController.php',
'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 commit hash querying to DiffusionLowLevelCommitQuery Summary: Ref T4195. I need this for the Herald pre-commit rules, and it generally simplifies things. Test Plan: Used `reparse.php` plus `var_dump()` to inspect refs in Git, Mercurial and SVN repos. They all looked correct and reparsed correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7804
2013-12-20 21:38:15 +01:00
'DiffusionCommitHash' => 'applications/diffusion/data/DiffusionCommitHash.php',
Install pre-commit hooks in Git repositories Summary: Ref T4189. T4189 describes most of the intent here: - When updating hosted repositories, sync a pre-commit hook into them instead of doing a `git fetch`. - The hook calls into Phabricator. The acting Phabricator user is sent via PHABRICATOR_USER in the environment. The active repository is sent via CLI. - The hook doesn't do anything useful yet; it just veifies basic parameters, does a little parsing, and exits 0 to allow the commit. Test Plan: - Performed Git pushes and pulls over SSH and HTTP. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7682
2013-12-03 00:45:36 +01:00
'DiffusionCommitHookEngine' => 'applications/diffusion/engine/DiffusionCommitHookEngine.php',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionCommitHookRejectException' => 'applications/diffusion/exception/DiffusionCommitHookRejectException.php',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'applications/diffusion/query/DiffusionCommitQuery.php',
Move git commit metadata parsing into a LowLevelQuery Summary: Ref T4195. I need to issue this command from the pre-commit hook to get commit bodies for hooks. Test Plan: Ran `reparse.php --message --trace` and dumped the $ref, which looked correct. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7793
2013-12-19 02:48:06 +01:00
'DiffusionCommitRef' => 'applications/diffusion/data/DiffusionCommitRef.php',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionCommitRemarkupRule' => 'applications/diffusion/remarkup/DiffusionCommitRemarkupRule.php',
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',
Add commits/audits to Asana bridge Summary: Ref T2852. Adds sync for commits/audits. Test Plan: {F51660} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6573
2013-07-26 19:31:35 +02:00
'DiffusionDoorkeeperCommitFeedStoryPublisher' => 'applications/diffusion/doorkeeper/DiffusionDoorkeeperCommitFeedStoryPublisher.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionEmptyResultView' => 'applications/diffusion/view/DiffusionEmptyResultView.php',
'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
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionGitFileContentQuery.php',
Allow parenthesis in author name Summary: We have a dozen users who has `(...)` in their 'real name', like 'Jimmy (He) Zhang', and it's causing the diffusion file browser problems when blame is enabled. The parser does not expect those parenthesis and the lines of code will be empty if they were last touched by a user like that. Test Plan: Try it Reviewers: wez, lifeihuang, JoelB, #blessed_reviewers, epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8429
2014-03-06 20:28:46 +01:00
'DiffusionGitFileContentQueryTestCase' => 'applications/diffusion/query/__tests__/DiffusionGitFileContentQueryTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionGitRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionGitRawDiffQuery.php',
'DiffusionGitRequest' => 'applications/diffusion/request/DiffusionGitRequest.php',
Serve Git reads over HTTP Summary: Mostly ripped from D7391. No writes yet. Test Plan: Ran `git clone` against a local over HTTP, got a clone. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7423
2013-10-26 21:10:52 +02:00
'DiffusionGitResponse' => 'applications/diffusion/response/DiffusionGitResponse.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
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',
Implement a lint count query Summary: Ref T2683. This query is currently unbatched and happens inside a view. Leave it inside the view for now, but separate it and make it batchable. Test Plan: {F34848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, vrana, aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5252
2014-05-11 00:21:05 +02:00
'DiffusionLintCountQuery' => 'applications/diffusion/query/DiffusionLintCountQuery.php',
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 commit message/metadata field query to a separate class Summary: Ref T4195. I need to query commit metadata to figure out which revision a commit is associated with. Move this out of the MessageParser so the code can be called from the HookEngine. Test Plan: Used `reparse.php` to reparse a variety of SVN, Mercurial and Git commits. Used `var_dump()` to verify sensible fields were returned. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7805
2013-12-20 21:38:44 +01:00
'DiffusionLowLevelCommitFieldsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelCommitFieldsQuery.php',
Provide a low-level SVN commit query, and merge the VCS query types Summary: Ref T4195. Even though we use `svnlook` in the hook itself, I need this query elsewhere, so provide it and merge the classes into one which does the right thing. Test Plan: - Used `reparse.php` to reparse messages for Git, SVN and Mercurial commits, using `var_dump()` to examine the commit refs for sanity. - Used `reparse.php` to reparse changes for an SVN commit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7800
2013-12-19 20:05:06 +01:00
'DiffusionLowLevelCommitQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelCommitQuery.php',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelGitRefQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelGitRefQuery.php',
Clean up `hg --debug branches` calls Summary: Ref T1493. Consolidate these a bit; they might need some more magic once we do `--noupdate` checkouts. Mostly just trying to clean up and centralize this code a bit. Test Plan: Viewed and `bin/repository discover`'d Mercurial repos with and without any branches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7480
2013-11-04 21:15:32 +01:00
'DiffusionLowLevelMercurialBranchesQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelMercurialBranchesQuery.php',
Modernize Diffusion `commitparentsquery` Summary: Ref T4195. Ref T2783. We have an old-school implementation of this; move it into a LowLevel query and make callers all run through Conduit. I need the LowLevel query for hooks, to implement an "is merge commit" Herald rule. Test Plan: - Ran query via Conduit for SVN, Mercurial, Git. - Parsed a commit which closed a revision, attach/closed worked correctly. - Browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195, T2783 Differential Revision: https://secure.phabricator.com/D7808
2013-12-20 21:39:21 +01:00
'DiffusionLowLevelParentsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelParentsQuery.php',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelQuery.php',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'DiffusionLowLevelResolveRefsQuery' => 'applications/diffusion/query/lowlevel/DiffusionLowLevelResolveRefsQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionMercurialFileContentQuery.php',
'DiffusionMercurialRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionMercurialRawDiffQuery.php',
'DiffusionMercurialRequest' => 'applications/diffusion/request/DiffusionMercurialRequest.php',
Allow Phabricator to serve Mercurial repositories over HTTP Summary: Ref T2230. This is easily the worst thing I've had to write in a while. I'll leave some notes inline. Test Plan: Ran `hg clone http://...` on a hosted repo. Ran `hg push` on the same. Changed sync'd both ways. Reviewers: asherkin, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7520
2013-11-07 03:00:42 +01:00
'DiffusionMercurialResponse' => 'applications/diffusion/response/DiffusionMercurialResponse.php',
'DiffusionMercurialWireProtocol' => 'applications/diffusion/protocol/DiffusionMercurialWireProtocol.php',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'DiffusionMirrorDeleteController' => 'applications/diffusion/controller/DiffusionMirrorDeleteController.php',
'DiffusionMirrorEditController' => 'applications/diffusion/controller/DiffusionMirrorEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionPathChange' => 'applications/diffusion/data/DiffusionPathChange.php',
'DiffusionPathChangeQuery' => 'applications/diffusion/query/pathchange/DiffusionPathChangeQuery.php',
'DiffusionPathCompleteController' => 'applications/diffusion/controller/DiffusionPathCompleteController.php',
'DiffusionPathIDQuery' => 'applications/diffusion/query/pathid/DiffusionPathIDQuery.php',
'DiffusionPathQuery' => 'applications/diffusion/query/DiffusionPathQuery.php',
'DiffusionPathQueryTestCase' => 'applications/diffusion/query/pathid/__tests__/DiffusionPathQueryTestCase.php',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'DiffusionPathTreeController' => 'applications/diffusion/controller/DiffusionPathTreeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionPathValidateController' => 'applications/diffusion/controller/DiffusionPathValidateController.php',
Provide an "event" page for push logs, which shows details on all events in a given push Summary: Ref T4677. This shows a more detailed view of an entire "git push", "hg push", or "svn commit". This is mostly to give push summary emails a reasonable, stable URI to link to for T4677. Test Plan: - Pushed into SVN, Git and Mercurial. - Viewed partial and imported event records. {F134864} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8616
2014-03-26 15:42:30 +01:00
'DiffusionPushEventViewController' => 'applications/diffusion/controller/DiffusionPushEventViewController.php',
'DiffusionPushLogController' => 'applications/diffusion/controller/DiffusionPushLogController.php',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'DiffusionPushLogListController' => 'applications/diffusion/controller/DiffusionPushLogListController.php',
Move Push log rendering to SearchEngine Summary: Ref T4986. Move push logs to a View, then have all the stuff that needs to use it use that View. Test Plan: Viewed push logs and transaction detail in Diffusion. Created a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9104
2014-05-13 23:00:24 +02:00
'DiffusionPushLogListView' => 'applications/diffusion/view/DiffusionPushLogListView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Throw a more tailored exception after failing to resolve a ref Summary: Ref T2683. Throw a more tailored exception to allow callers to distinguish between bad refs (which are expected, if users try to visit garbage branches) and other types of errors. Test Plan: Tried to view branch "alksndfklansdf". Viewed branch "master". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9094
2014-05-13 22:52:33 +02:00
'DiffusionRefNotFoundException' => 'applications/diffusion/exception/DiffusionRefNotFoundException.php',
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',
Build an early multi-step repository create form Summary: Ref T2231. Ref T2232. This form doesn't do anything yet and there are no link sto it, but it lets you enter all the data to create a repository in a relatively simple, straightforward way. Test Plan: {F49740} {F49741} {F49742} {F49743} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231, T2232 Differential Revision: https://secure.phabricator.com/D6430
2013-07-14 16:37:17 +02:00
'DiffusionRepositoryCreateController' => 'applications/diffusion/controller/DiffusionRepositoryCreateController.php',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'DiffusionRepositoryDefaultController' => 'applications/diffusion/controller/DiffusionRepositoryDefaultController.php',
Move repository actions (notify, autoclose) to new UI Summary: Ref T2231. Brings "Notify/Publish" and "Autoclose" to the new UI. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7402
2013-10-25 22:58:15 +02:00
'DiffusionRepositoryEditActionsController' => 'applications/diffusion/controller/DiffusionRepositoryEditActionsController.php',
Allow repositories to be activate/deactivated in a transaction-aware way Summary: Adds activate/deactivate action plus transactions. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7057
2013-09-22 01:23:35 +02:00
'DiffusionRepositoryEditActivateController' => 'applications/diffusion/controller/DiffusionRepositoryEditActivateController.php',
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',
Add support for branch-related configuration to new Repository edit workflow Summary: Ref T2231. Modernizes editing "Default Branch", "Track Only", and "Autoclose Only". Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7399
2013-10-25 22:57:14 +02:00
'DiffusionRepositoryEditBranchesController' => 'applications/diffusion/controller/DiffusionRepositoryEditBranchesController.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'DiffusionRepositoryEditController' => 'applications/diffusion/controller/DiffusionRepositoryEditController.php',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionRepositoryEditDangerousController' => 'applications/diffusion/controller/DiffusionRepositoryEditDangerousController.php',
Proteins
2013-10-29 22:23:30 +01:00
'DiffusionRepositoryEditDeleteController' => 'applications/diffusion/controller/DiffusionRepositoryEditDeleteController.php',
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',
Add hosting, serving, and push policy options to repository edit Summary: Basically straight from D7391. The differences are basically: - Policy stuff is all application-scope instead of global-scope. - Made a few strings a little nicer. - Deleted a bit of dead code. - Added a big "THIS DOESN'T WORK YET" warning. Test Plan: See screenshots. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7416
2013-10-26 05:13:38 +02:00
'DiffusionRepositoryEditHostingController' => 'applications/diffusion/controller/DiffusionRepositoryEditHostingController.php',
Move editing "Local Path" to modern UI/controller/etc Summary: Fixes T1286. Ref T2231. See previous diffs; same as the others but does "Local Path". Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7409
2013-10-29 20:20:26 +01:00
'DiffusionRepositoryEditLocalController' => 'applications/diffusion/controller/DiffusionRepositoryEditLocalController.php',
Sort out application crumbs in new repository edit workflow Summary: Ref T2231. Crumbs in the Diffusion edit workflow are a bit wonky, with stuff like "rP (master)" which isn't very useful and no link back to the main "Edit" page. Make them consistent across all the screens. Test Plan: Loaded a bunch of these screens and saw sane crumbs on all of them. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7407
2013-10-26 00:58:58 +02:00
'DiffusionRepositoryEditMainController' => 'applications/diffusion/controller/DiffusionRepositoryEditMainController.php',
Move Subversion repository information to the new interface Summary: Ref T2231. Moves "UUID" and "Subpath/Import Only" to Diffusion. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7400
2013-10-25 22:58:03 +02:00
'DiffusionRepositoryEditSubversionController' => 'applications/diffusion/controller/DiffusionRepositoryEditSubversionController.php',
Rename `DiffusionHomeController` to `DiffusionRepositoryListController` Summary: Improves consistency across applications. Test Plan: Loaded `/diffusion/`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6916
2013-09-11 00:24:44 +02:00
'DiffusionRepositoryListController' => 'applications/diffusion/controller/DiffusionRepositoryListController.php',
When creating a repository in Diffusion, prompt for "Create" or "Import" first Summary: Ref T2230. This will need some more refinement, but basically it adds a "Create" vs "Import" step before we go through the paged workflow. - If you choose "Create", we skip the remote URI / auth stuff, and then set the "hosted" flag. - If you choose "Import", we do what we do now. Test Plan: Created and imported repos. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7475
2013-11-02 01:39:35 +01:00
'DiffusionRepositoryNewController' => 'applications/diffusion/controller/DiffusionRepositoryNewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionRepositoryRef' => 'applications/diffusion/data/DiffusionRepositoryRef.php',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionRepositoryRemarkupRule' => 'applications/diffusion/remarkup/DiffusionRepositoryRemarkupRule.php',
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',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'DiffusionResolveUserQuery' => 'applications/diffusion/query/DiffusionResolveUserQuery.php',
Serve git writes over SSH Summary: Looks like this is pretty straightforward; same as the reads except mark it as needing PUSH. Test Plan: Ran `git push`, pushed over SSH to a hosted repo. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7425
2013-10-26 23:11:52 +02:00
'DiffusionSSHGitReceivePackWorkflow' => 'applications/diffusion/ssh/DiffusionSSHGitReceivePackWorkflow.php',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHGitUploadPackWorkflow' => 'applications/diffusion/ssh/DiffusionSSHGitUploadPackWorkflow.php',
'DiffusionSSHGitWorkflow' => 'applications/diffusion/ssh/DiffusionSSHGitWorkflow.php',
Enable Mercurial reads and writes over SSH Summary: Ref T2230. This is substantially more complicated than Git, but mostly because Mercurial's protocol is a like 50 ad-hoc extensions cobbled together. Because we must decode protocol frames in order to determine if a request is read or write, 90% of this is implementing a stream parser for the protocol. Mercurial's own parser is simpler, but relies on blocking reads. Since we don't even have methods for blocking reads right now and keeping the whole thing non-blocking is conceptually better, I made the parser nonblocking. It ends up being a lot of stuff. I made an effort to cover it reasonably well with unit tests, and to make sure we fail closed (i.e., reject requests) if there are any parts of the protocol I got wrong. A lot of the complexity is sharable with the HTTP stuff, so it ends up being not-so-bad, just very hard to verify by inspection as clearly correct. Test Plan: - Ran `hg clone` over SSH. - Ran `hg fetch` over SSH. - Ran `hg push` over SSH, to a read-only repo (error) and a read-write repo (success). Reviewers: btrahan, asherkin Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7553
2013-11-11 21:18:27 +01:00
'DiffusionSSHMercurialServeWorkflow' => 'applications/diffusion/ssh/DiffusionSSHMercurialServeWorkflow.php',
'DiffusionSSHMercurialWireClientProtocolChannel' => 'applications/diffusion/ssh/DiffusionSSHMercurialWireClientProtocolChannel.php',
'DiffusionSSHMercurialWireTestCase' => 'applications/diffusion/ssh/__tests__/DiffusionSSHMercurialWireTestCase.php',
'DiffusionSSHMercurialWorkflow' => 'applications/diffusion/ssh/DiffusionSSHMercurialWorkflow.php',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSSHSubversionServeWorkflow' => 'applications/diffusion/ssh/DiffusionSSHSubversionServeWorkflow.php',
'DiffusionSSHSubversionWorkflow' => 'applications/diffusion/ssh/DiffusionSSHSubversionWorkflow.php',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHWorkflow' => 'applications/diffusion/ssh/DiffusionSSHWorkflow.php',
Split Diffusion VSC serve code into its own controller Summary: This is starting to get a bit sizable and it turns out Mercurial is sort of a beast, so split the VCS serve stuff into a separate controller. Test Plan: Pushed and pulled an authenticated Git repository. Reviewers: btrahan Reviewed By: btrahan CC: aran, hach-que Differential Revision: https://secure.phabricator.com/D7494
2013-11-07 02:55:46 +01:00
'DiffusionServeController' => 'applications/diffusion/controller/DiffusionServeController.php',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'DiffusionSetPasswordPanel' => 'applications/diffusion/panel/DiffusionSetPasswordPanel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSetupException' => 'applications/diffusion/exception/DiffusionSetupException.php',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSubversionWireProtocol' => 'applications/diffusion/protocol/DiffusionSubversionWireProtocol.php',
'DiffusionSubversionWireProtocolTestCase' => 'applications/diffusion/protocol/__tests__/DiffusionSubversionWireProtocolTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/DiffusionSvnFileContentQuery.php',
'DiffusionSvnRawDiffQuery' => 'applications/diffusion/query/rawdiff/DiffusionSvnRawDiffQuery.php',
'DiffusionSvnRequest' => 'applications/diffusion/request/DiffusionSvnRequest.php',
'DiffusionSymbolController' => 'applications/diffusion/controller/DiffusionSymbolController.php',
'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',
Diviner Book Index styles Summary: Slightly more readable, less space than current index. LMK if you hate it though. Test Plan: Look at user and dev book indexes. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6932
2013-09-10 18:39:50 +02:00
'DivinerBookItemView' => 'applications/diviner/view/DivinerBookItemView.php',
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',
Diviner: improve links, book index, and atom view Summary: Ref T988. Minor improvements to diviner: link stuff to a valid endpoint which actually works; fix group names on the book index; improve the topics index for atom views. Test Plan: Clicked links in an article, viewed book index, viewed an article with long headers. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6598
2013-07-28 22:07:30 +02:00
'DivinerFindController' => 'applications/diviner/controller/DivinerFindController.php',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerGenerateWorkflow' => 'applications/diviner/workflow/DivinerGenerateWorkflow.php',
Add "live" publisher and storage to Diviner Summary: Ref T988. This adds basics for the non-static publishing target: - Storage (called "Live", e.g. `DivinerLiveAtom` to distinguish it from shared classes like `DivinerAtom`). - Mostly populate the storage. - Some minor fixes and improvements. Test Plan: Generated docs, looked at DB, saw mostly-sensible output. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D5973
2013-05-20 19:18:26 +02:00
'DivinerLiveAtom' => 'applications/diviner/storage/DivinerLiveAtom.php',
'DivinerLiveBook' => 'applications/diviner/storage/DivinerLiveBook.php',
'DivinerLivePublisher' => 'applications/diviner/publisher/DivinerLivePublisher.php',
'DivinerLiveSymbol' => 'applications/diviner/storage/DivinerLiveSymbol.php',
Give Diviner a non-legacy root controller Summary: Ref T988. Instead of hard-coding the application landing page, make the Diviner root show books if any have been generated. Otherwise, show a helpful message about how to generate documentation locally. Test Plan: {F122723} {F122724} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D8416
2014-03-05 22:07:50 +01:00
'DivinerMainController' => 'applications/diviner/controller/DivinerMainController.php',
Use application PHIDs for ATOM Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6597
2013-07-30 15:49:13 +02:00
'DivinerPHIDTypeAtom' => 'applications/diviner/phid/DivinerPHIDTypeAtom.php',
Use application PHIDs for Diviner Books Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6596
2013-07-30 15:47:07 +02:00
'DivinerPHIDTypeBook' => 'applications/diviner/phid/DivinerPHIDTypeBook.php',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerPHPAtomizer' => 'applications/diviner/atomizer/DivinerPHPAtomizer.php',
'DivinerParameterTableView' => 'applications/diviner/view/DivinerParameterTableView.php',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'applications/diviner/cache/DivinerPublishCache.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerPublisher' => 'applications/diviner/publisher/DivinerPublisher.php',
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',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerReturnTableView' => 'applications/diviner/view/DivinerReturnTableView.php',
More Diviner style updates Summary: This adds a number of new styles for Diviner documentation. Not sure I've covered all the bases or wrote this in the most efficient manner, but passing it along now for early review before tightening everything up. Test Plan: Review various class pages. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6888
2013-09-05 21:29:07 +02:00
'DivinerSectionView' => 'applications/diviner/view/DivinerSectionView.php',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerStaticPublisher' => 'applications/diviner/publisher/DivinerStaticPublisher.php',
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',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperBridge' => 'applications/doorkeeper/bridge/DoorkeeperBridge.php',
'DoorkeeperBridgeAsana' => 'applications/doorkeeper/bridge/DoorkeeperBridgeAsana.php',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperBridgeJIRA' => 'applications/doorkeeper/bridge/DoorkeeperBridgeJIRA.php',
Fix JIRA issue URI selection for JIRA installs which are not on the domain root Summary: Fixes T4859. See that for details. Test Plan: - Verified things still work on my local (domain root) install. - Added some unit tests. - Did not verify a non-root install since I don't have one handy, hopefully @salehe can help. Reviewers: btrahan Reviewed By: btrahan Subscribers: salehe, epriestley Maniphest Tasks: T4859 Differential Revision: https://secure.phabricator.com/D8836
2014-05-18 14:45:21 +02:00
'DoorkeeperBridgeJIRATestCase' => 'applications/doorkeeper/bridge/__tests__/DoorkeeperBridgeJIRATestCase.php',
Add DoorkeeperExternalObject Summary: Ref T2852. This table holds data about external objects and allows us to write edges to them. Objects are identified with an `<applicationType, applicationDomain, objectType, objectID>` tuple. For example, Asana tasks will be, e.g., `<asana, asana.com, asana:task, 93829279873>` or similar. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6271
2013-06-25 00:54:36 +02:00
'DoorkeeperDAO' => 'applications/doorkeeper/storage/DoorkeeperDAO.php',
'DoorkeeperExternalObject' => 'applications/doorkeeper/storage/DoorkeeperExternalObject.php',
Add DoorkeeperExternalObjectQuery, expose more ref/import APIs Summary: Ref T2852. - Broadly, we support "I have a Ref, I need a PHID" well but not "I have a PHID, I need a Ref". - Add DoorkeeperExternalObjectQuery, and use it to query ExternalObjects. - Allow external objects to be imported by their internal PHIDs. Basically, if we have an edge pointing at an ExternalObject, we can say "load all the data about this" from just the PHID and have it hit all the same code. - Allow construction of Refs from ExternalObjects. This makes the "I have a PHID, I need a Ref" easier. Test Plan: - Verified Asana links still enrich properly at display time. - Used in future revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6294
2013-06-26 01:30:44 +02:00
'DoorkeeperExternalObjectQuery' => 'applications/doorkeeper/query/DoorkeeperExternalObjectQuery.php',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DoorkeeperFeedStoryPublisher' => 'applications/doorkeeper/engine/DoorkeeperFeedStoryPublisher.php',
Refactor shared code between JIRA + Asana publishers into a base class Summary: Ref T3687. See some discussion in D6892. The JIRA doorkeeper publisher shares a reasonable amount of code with the Asana publisher. Remedy this: - Create `DoorkeeperFeedWorker`, where shared functionality lives (mostly related to building story context objects). - Push responsibility for enabling/disabling a worker into this new layer, via `isEnabled()`. This allows `FeedPublisherWorker` to dynamically find and schedule doorkeeper publishers, so third parties can add additional doorkeeper publishers. - Some general cleanup/documentation. Test Plan: Used `bin/feed republish` to republish stories about objects with JIRA and Asana links. Verified that doorkeeper publishers activated properly, made calls, and published events into the remote systems. Reviewers: btrahan, akopanev22 Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6906
2013-09-11 00:22:01 +02:00
'DoorkeeperFeedWorker' => 'applications/doorkeeper/worker/DoorkeeperFeedWorker.php',
Initial Asana sync for Differential Summary: Ref T2852. This is highly incomplete but seems structurally sound. Some additional context is available in the Google doc. - Add a workspace ID configuration. Without it, nothing else activates. - Add a worker which reacts to feed stories. - Feed stories about things which aren't Differential objects are ignored. - We load the revision, or fail permanently if we can't. - We get all the related user PHIDs (author, reviewers, CCs). - We check if any of them have linked Asana accounts, or fail permanently if they don't. - We check for an "ASANATASK" edge from the revision. - If we do not find one, we create a new task. - If we do find one, we load the task. - If we succeed, we check the chronological key of the most recent synchronized feed story ("cursor"). - If this story is the same or newer, we update the task to synchronize it to the current state of the revision. - If we fail to load the task, we fail permanently ("asana task has been deleted"). - We then publish the actual story text to the task. Not in yet: - Updating followers requires separate API calls which we don't do yet. - No subtasks yet. - No sync of open/closed state. Test Plan: {F47546} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6302
2013-06-26 01:33:16 +02:00
'DoorkeeperFeedWorkerAsana' => 'applications/doorkeeper/worker/DoorkeeperFeedWorkerAsana.php',
Publish Doorkeeper object stories to JIRA Summary: Ref T3687. Publish stories into JIRA. These need some voicing fixes, which maybe involves straightening out the feed code. For example, they're voiced in-context ("updated this revision") when they should be voiced out-of-context ("updated D123"). Generally, this is similar to the Asana stuff but a lot simpler since we don't need to do any state management. Test Plan: {F57366} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6892
2013-09-06 01:51:20 +02:00
'DoorkeeperFeedWorkerJIRA' => 'applications/doorkeeper/worker/DoorkeeperFeedWorkerJIRA.php',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperImportEngine' => 'applications/doorkeeper/engine/DoorkeeperImportEngine.php',
Make "JIRA Issues" field work better with noncredentialed accounts Summary: Currently, users get an error when making any changes to this field if they don't have a linked JIRA account. Instead: - We should only raise an error if they're trying to //add// issues, and only on the new issues. It's always fine to remove issues, and existing issues the author can't see are also fine. - When we can't add things because there's no account (vs because there's a permissions error or they don't exist), raise a more tailored exception. Test Plan: - As JIRA and non-JIRA users, made various edits to this field. - Got appropriate exceptions, including better tailoring. Reviewers: btrahan Reviewed By: btrahan Subscribers: mbishopim3, epriestley Differential Revision: https://secure.phabricator.com/D8676
2014-04-02 21:03:59 +02:00
'DoorkeeperMissingLinkException' => 'applications/doorkeeper/exception/DoorkeeperMissingLinkException.php',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperObjectRef' => 'applications/doorkeeper/engine/DoorkeeperObjectRef.php',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperRemarkupRule' => 'applications/doorkeeper/remarkup/DoorkeeperRemarkupRule.php',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperRemarkupRuleAsana' => 'applications/doorkeeper/remarkup/DoorkeeperRemarkupRuleAsana.php',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperRemarkupRuleJIRA' => 'applications/doorkeeper/remarkup/DoorkeeperRemarkupRuleJIRA.php',
Render linked JIRA issues with a Doorkeeper tag Summary: Fixes T3687. Instead of rendering "JIRA Issues" in Differential using plain links, render them using Doorkeeper tags so they get the nice "enhance with object name" effect. Test Plan: {F84886} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D7648
2013-11-25 23:54:35 +01:00
'DoorkeeperTagView' => 'applications/doorkeeper/view/DoorkeeperTagView.php',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperTagsController' => 'applications/doorkeeper/controller/DoorkeeperTagsController.php',
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',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprint' => 'applications/drydock/storage/DrydockBlueprint.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintController' => 'applications/drydock/controller/DrydockBlueprintController.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintCreateController' => 'applications/drydock/controller/DrydockBlueprintCreateController.php',
'DrydockBlueprintEditController' => 'applications/drydock/controller/DrydockBlueprintEditController.php',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintEditor' => 'applications/drydock/editor/DrydockBlueprintEditor.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintImplementation' => 'applications/drydock/blueprint/DrydockBlueprintImplementation.php',
'DrydockBlueprintListController' => 'applications/drydock/controller/DrydockBlueprintListController.php',
'DrydockBlueprintQuery' => 'applications/drydock/query/DrydockBlueprintQuery.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',
Use ApplicationSearch for Drydock Blueprints Summary: Ref T2015. This turns the side nav into a bigger mess for now, but uses ApplicationSearch for blueprints. Test Plan: Queried blueprints in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7829
2013-12-26 21:30:04 +01:00
'DrydockBlueprintSearchEngine' => 'applications/drydock/query/DrydockBlueprintSearchEngine.php',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintTransaction' => 'applications/drydock/storage/DrydockBlueprintTransaction.php',
'DrydockBlueprintTransactionQuery' => 'applications/drydock/query/DrydockBlueprintTransactionQuery.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprintViewController' => 'applications/drydock/controller/DrydockBlueprintViewController.php',
Add Drydock default edit/view policies and a "Create Blueprint" policy Summary: Ref T2015. Allow configuration of default edit/view policies for blueprints. Add create policy. Remove administrative exception in policies. Test Plan: Configured these settings and created (or, with a restrictive create setting, tried to create) blueprints. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7921
2014-01-09 21:19:45 +01:00
'DrydockCapabilityCreateBlueprints' => 'applications/drydock/capability/DrydockCapabilityCreateBlueprints.php',
'DrydockCapabilityDefaultEdit' => 'applications/drydock/capability/DrydockCapabilityDefaultEdit.php',
'DrydockCapabilityDefaultView' => 'applications/drydock/capability/DrydockCapabilityDefaultView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockConsoleController' => 'applications/drydock/controller/DrydockConsoleController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockConstants' => 'applications/drydock/constants/DrydockConstants.php',
'DrydockController' => 'applications/drydock/controller/DrydockController.php',
'DrydockDAO' => 'applications/drydock/storage/DrydockDAO.php',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockFilesystemInterface' => 'applications/drydock/interface/filesystem/DrydockFilesystemInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockInterface' => 'applications/drydock/interface/DrydockInterface.php',
'DrydockLease' => 'applications/drydock/storage/DrydockLease.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseController' => 'applications/drydock/controller/DrydockLeaseController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLeaseListController' => 'applications/drydock/controller/DrydockLeaseListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLeaseListView' => 'applications/drydock/view/DrydockLeaseListView.php',
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',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
'DrydockLeaseSearchEngine' => 'applications/drydock/query/DrydockLeaseSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLeaseStatus' => 'applications/drydock/constants/DrydockLeaseStatus.php',
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',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockLocalHostBlueprintImplementation' => 'applications/drydock/blueprint/DrydockLocalHostBlueprintImplementation.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLog' => 'applications/drydock/storage/DrydockLog.php',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLogController' => 'applications/drydock/controller/DrydockLogController.php',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogListController' => 'applications/drydock/controller/DrydockLogListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLogListView' => 'applications/drydock/view/DrydockLogListView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockLogQuery' => 'applications/drydock/query/DrydockLogQuery.php',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogSearchEngine' => 'applications/drydock/query/DrydockLogSearchEngine.php',
Add 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',
Drydock blueprint for preallocated remote hosts Summary: This adds a Drydock blueprint for preallocated, remote hosts. This will be used by the Harbormaster interface to allow users to specify remote hosts that builds can be run on. This adds a `canAllocateResource` method to Drydock blueprints; it is used to detect whether a blueprint can allocate a resource for the given type and attributes. Test Plan: Ran: ``` bin/drydock lease --type host --attributes remote=true,preallocated=true,host=192.168.56.101,port=22,user=james,keyfile=,path=C:\\Build\\,platform=windows ``` and saw the "C:\Build\<id>" folder appear on the remote Windows machine. Viewed the lease and resource in Drydock as well. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T4111 Differential Revision: https://secure.phabricator.com/D7593
2013-11-22 23:34:09 +01:00
'DrydockManagementCreateResourceWorkflow' => 'applications/drydock/management/DrydockManagementCreateResourceWorkflow.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
'DrydockManagementWorkflow' => 'applications/drydock/management/DrydockManagementWorkflow.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockPHIDTypeBlueprint' => 'applications/drydock/phid/DrydockPHIDTypeBlueprint.php',
Make Drydock Lease and Resource PHIDs use newer PHID infrastructure Summary: Ref T2015. These never got updated to the new stuff, move them out of the old `Constants` class and let them load handles, etc. Also some half-cleanup of some Blueprint/BlueprintImplementation stuff. Test Plan: Used `phid.query` to query a Resource, Lease, and Blueprint. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7828
2013-12-26 21:29:58 +01:00
'DrydockPHIDTypeLease' => 'applications/drydock/phid/DrydockPHIDTypeLease.php',
'DrydockPHIDTypeResource' => 'applications/drydock/phid/DrydockPHIDTypeResource.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockPreallocatedHostBlueprintImplementation' => 'applications/drydock/blueprint/DrydockPreallocatedHostBlueprintImplementation.php',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockQuery' => 'applications/drydock/query/DrydockQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceController' => 'applications/drydock/controller/DrydockResourceController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceListController' => 'applications/drydock/controller/DrydockResourceListController.php',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockResourceListView' => 'applications/drydock/view/DrydockResourceListView.php',
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',
Use ApplicationSearch for Drydock Resources Summary: Ref T2015. Bring ApplicationSearch to Resources, too. Test Plan: Browsed/queried resources in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7830
2013-12-26 21:30:10 +01:00
'DrydockResourceSearchEngine' => 'applications/drydock/query/DrydockResourceSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockResourceStatus' => 'applications/drydock/constants/DrydockResourceStatus.php',
Add a detail view for resources in Drydock Summary: Nothing fancy here, just add a detail page. Test Plan: Looked at detail page. {F24808} Reviewers: btrahan Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D3995
2012-11-20 22:25:22 +01:00
'DrydockResourceViewController' => 'applications/drydock/controller/DrydockResourceViewController.php',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockSFTPFilesystemInterface' => 'applications/drydock/interface/filesystem/DrydockSFTPFilesystemInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/DrydockSSHCommandInterface.php',
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/DrydockWebrootInterface.php',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockWorkingCopyBlueprintImplementation' => 'applications/drydock/blueprint/DrydockWorkingCopyBlueprintImplementation.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPublisherHTTPWorker' => 'applications/feed/worker/FeedPublisherHTTPWorker.php',
post feed stories to arbitrary uris via a new Worker Summary: so folks can write applications and whatnot. Test Plan: set feed.http-hooks to local dev instance (200) and localhost (500) in my conf. Verified succcess and retrying respectively. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T305 Differential Revision: https://secure.phabricator.com/D3874
2012-11-02 21:34:18 +01:00
'FeedPublisherWorker' => 'applications/feed/worker/FeedPublisherWorker.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPushWorker' => 'applications/feed/worker/FeedPushWorker.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileCreateMailReceiver' => 'applications/files/mail/FileCreateMailReceiver.php',
'FileMailReceiver' => 'applications/files/mail/FileMailReceiver.php',
'FileReplyHandler' => 'applications/files/mail/FileReplyHandler.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuild' => 'applications/harbormaster/storage/build/HarbormasterBuild.php',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildActionController' => 'applications/harbormaster/controller/HarbormasterBuildActionController.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildArtifact' => 'applications/harbormaster/storage/build/HarbormasterBuildArtifact.php',
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
'HarbormasterBuildArtifactQuery' => 'applications/harbormaster/query/HarbormasterBuildArtifactQuery.php',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildCommand' => 'applications/harbormaster/storage/HarbormasterBuildCommand.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildEngine' => 'applications/harbormaster/engine/HarbormasterBuildEngine.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildItem' => 'applications/harbormaster/storage/build/HarbormasterBuildItem.php',
'HarbormasterBuildItemQuery' => 'applications/harbormaster/query/HarbormasterBuildItemQuery.php',
'HarbormasterBuildLog' => 'applications/harbormaster/storage/build/HarbormasterBuildLog.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildLogQuery' => 'applications/harbormaster/query/HarbormasterBuildLogQuery.php',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'HarbormasterBuildMessage' => 'applications/harbormaster/storage/HarbormasterBuildMessage.php',
'HarbormasterBuildMessageQuery' => 'applications/harbormaster/query/HarbormasterBuildMessageQuery.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlan' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlan.php',
'HarbormasterBuildPlanEditor' => 'applications/harbormaster/editor/HarbormasterBuildPlanEditor.php',
'HarbormasterBuildPlanQuery' => 'applications/harbormaster/query/HarbormasterBuildPlanQuery.php',
'HarbormasterBuildPlanSearchEngine' => 'applications/harbormaster/query/HarbormasterBuildPlanSearchEngine.php',
'HarbormasterBuildPlanTransaction' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlanTransaction.php',
'HarbormasterBuildPlanTransactionComment' => 'applications/harbormaster/storage/configuration/HarbormasterBuildPlanTransactionComment.php',
'HarbormasterBuildPlanTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildPlanTransactionQuery.php',
'HarbormasterBuildQuery' => 'applications/harbormaster/query/HarbormasterBuildQuery.php',
'HarbormasterBuildStep' => 'applications/harbormaster/storage/configuration/HarbormasterBuildStep.php',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepCoreCustomField' => 'applications/harbormaster/customfield/HarbormasterBuildStepCoreCustomField.php',
'HarbormasterBuildStepCustomField' => 'applications/harbormaster/customfield/HarbormasterBuildStepCustomField.php',
'HarbormasterBuildStepEditor' => 'applications/harbormaster/editor/HarbormasterBuildStepEditor.php',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterBuildStepImplementation.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildStepQuery' => 'applications/harbormaster/query/HarbormasterBuildStepQuery.php',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepTransaction' => 'applications/harbormaster/storage/configuration/HarbormasterBuildStepTransaction.php',
'HarbormasterBuildStepTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildStepTransactionQuery.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildTarget' => 'applications/harbormaster/storage/build/HarbormasterBuildTarget.php',
'HarbormasterBuildTargetQuery' => 'applications/harbormaster/query/HarbormasterBuildTargetQuery.php',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildTransaction' => 'applications/harbormaster/storage/HarbormasterBuildTransaction.php',
'HarbormasterBuildTransactionEditor' => 'applications/harbormaster/editor/HarbormasterBuildTransactionEditor.php',
'HarbormasterBuildTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildTransactionQuery.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildViewController' => 'applications/harbormaster/controller/HarbormasterBuildViewController.php',
Implement basic Harbormaster daemon and start builds. Summary: This implements a basic Harbormaster daemon that takes pending builds and builds them (currently just sleeps 15 seconds before moving to passed state). It also implements an interface to apply a build plan to a buildable, so that users can kick off builds for a buildable. Test Plan: Ran `bin/phd debug PhabricatorHarbormasterBuildDaemon` and used the interface to start some builds by applying a build plan. Observed them move from 'pending' to 'building' to 'passed'. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7498
2013-11-05 21:43:47 +01:00
'HarbormasterBuildWorker' => 'applications/harbormaster/worker/HarbormasterBuildWorker.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildable' => 'applications/harbormaster/storage/HarbormasterBuildable.php',
Allow entire buildables to restart/stop/resume Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds. Test Plan: - Stopped all builds. - Resumed all builds. - Restarted all builds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7899
2014-01-06 23:12:15 +01:00
'HarbormasterBuildableActionController' => 'applications/harbormaster/controller/HarbormasterBuildableActionController.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterBuildableInterface' => 'applications/harbormaster/interface/HarbormasterBuildableInterface.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableListController' => 'applications/harbormaster/controller/HarbormasterBuildableListController.php',
'HarbormasterBuildableQuery' => 'applications/harbormaster/query/HarbormasterBuildableQuery.php',
'HarbormasterBuildableSearchEngine' => 'applications/harbormaster/query/HarbormasterBuildableSearchEngine.php',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildableTransaction' => 'applications/harbormaster/storage/HarbormasterBuildableTransaction.php',
'HarbormasterBuildableTransactionEditor' => 'applications/harbormaster/editor/HarbormasterBuildableTransactionEditor.php',
'HarbormasterBuildableTransactionQuery' => 'applications/harbormaster/query/HarbormasterBuildableTransactionQuery.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableViewController' => 'applications/harbormaster/controller/HarbormasterBuildableViewController.php',
'HarbormasterCapabilityManagePlans' => 'applications/harbormaster/capability/HarbormasterCapabilityManagePlans.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterCommandBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterCommandBuildStepImplementation.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterController' => 'applications/harbormaster/controller/HarbormasterController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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 "Make an HTTP Request" build step Summary: Ref T1049. This is very minimal, but does what it says. I merged the variable replacement code so Remote + HTTP can share more stuff. Test Plan: Ran "HTTP" and "Remote" build plans. {F79886} {F79887} Reviewers: hach-que, btrahan Reviewed By: hach-que CC: zeeg, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7541
2013-11-09 16:16:12 +01:00
'HarbormasterHTTPRequestBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterHTTPRequestBuildStepImplementation.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterLeaseHostBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterLeaseHostBuildStepImplementation.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementBuildWorkflow' => 'applications/harbormaster/management/HarbormasterManagementBuildWorkflow.php',
Give Buildables a status, populate it, and return it over Conduit Summary: Ref T4809. Currently, buildables have a status field but nothing populates it. Populate it: - When builds change state, update the Buildable state. - Use the new Buildable state on the web UI. - Return the new Buildable state from Conduit. To make it easier to debug/test this: - Provide `bin/harbormaster update Bxxx ...` to force foreground update of a Buildable. Test Plan: - Used `bin/harbormaster update Bxxx --force --trace` to update buildables. - Looked at buidlable list, saw statuses reported properly. - Used Conduit to read statuses. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8799
2014-04-18 01:01:16 +02:00
'HarbormasterManagementUpdateWorkflow' => 'applications/harbormaster/management/HarbormasterManagementUpdateWorkflow.php',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementWorkflow' => 'applications/harbormaster/management/HarbormasterManagementWorkflow.php',
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',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPHIDTypeBuild' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuild.php',
'HarbormasterPHIDTypeBuildItem' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildItem.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterPHIDTypeBuildLog' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildLog.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPHIDTypeBuildPlan' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildPlan.php',
'HarbormasterPHIDTypeBuildStep' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildStep.php',
'HarbormasterPHIDTypeBuildTarget' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildTarget.php',
'HarbormasterPHIDTypeBuildable' => 'applications/harbormaster/phid/HarbormasterPHIDTypeBuildable.php',
'HarbormasterPlanController' => 'applications/harbormaster/controller/HarbormasterPlanController.php',
Allow Harbormaster build plans to be disabled Summary: Fixes T4187. Ref T1049. Allows build plans to be enabled or disabled. Test Plan: Enabled and disabled build plans. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4187, T1049 Differential Revision: https://secure.phabricator.com/D7822
2013-12-26 19:40:22 +01:00
'HarbormasterPlanDisableController' => 'applications/harbormaster/controller/HarbormasterPlanDisableController.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanEditController' => 'applications/harbormaster/controller/HarbormasterPlanEditController.php',
'HarbormasterPlanListController' => 'applications/harbormaster/controller/HarbormasterPlanListController.php',
Implement explicit build step ordering in Harbormaster Summary: This implements support for explicitly marking the sequence of build steps. Users can now drag and re-order build steps in plans, and artifact dependencies are re-calculated so that if you move "Run Command" before "Lease Host", the "Run Command" step has it's artifact setting cleared and thus the step becomes invalid. Test Plan: Re-ordered build steps and observed dependencies being correctly recalculated. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7715
2013-12-06 04:12:15 +01:00
'HarbormasterPlanOrderController' => 'applications/harbormaster/controller/HarbormasterPlanOrderController.php',
Formalize "manual" buildables in Harbormaster Summary: Ref T1049. Generally, it's useful to separate test/trial/manual runs from production/automatic runs. For example, you don't want to email a bunch of people that the build is broken just because you messed something up when writing a new build plan. You'd rather try it first, then promote it into production once you have some good runs. Similarly, test runs generally should not affect the outside world, etc. Finally, some build steps (like "wait for other buildables") may want to behave differently when run in production/automation than when run in a testing environment (where they should probably continue immediately). So, formalize the distinction between automatic buildables (those created passively by the system in response to events) and manual buildables (those created explicitly by users). Add filtering, and stop the automated parts of the system from interacting with the manual parts (for example, we won't show manual results on revisions). This also moves the "Apply Build Plan" to a third, new home: instead of the sidebar or Buildables, it's now on plans. I think this generally makes more sense given how things have developed. Broadly, this improves isolation of test environments. Test Plan: Created some builds, browsed around, used filters, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7824
2013-12-26 19:40:43 +01:00
'HarbormasterPlanRunController' => 'applications/harbormaster/controller/HarbormasterPlanRunController.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanViewController' => 'applications/harbormaster/controller/HarbormasterPlanViewController.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterPublishFragmentBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterPublishFragmentBuildStepImplementation.php',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterRemarkupRule' => 'applications/harbormaster/remarkup/HarbormasterRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HarbormasterScratchTable' => 'applications/harbormaster/storage/HarbormasterScratchTable.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterSleepBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterSleepBuildStepImplementation.php',
Implement interface for adding, editing and deleting build steps on plans. Summary: This implements an interface for adding new build steps, editing existing build steps and deleting build steps from build plans. It uses the settings definitions on the build implementation to work out what fields should be displayed on the edit page. Test Plan: See screenshots: {F78529} {F78532} {F78528} {F78531} {F78527} {F78530} Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7500
2013-11-05 22:54:03 +01:00
'HarbormasterStepAddController' => 'applications/harbormaster/controller/HarbormasterStepAddController.php',
'HarbormasterStepDeleteController' => 'applications/harbormaster/controller/HarbormasterStepDeleteController.php',
'HarbormasterStepEditController' => 'applications/harbormaster/controller/HarbormasterStepEditController.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterTargetWorker' => 'applications/harbormaster/worker/HarbormasterTargetWorker.php',
Improve several exception behaviors for Harbormaster workers Summary: Ref T2015. Several fixes: - `checkForCancellation()` no longer exists, and isn't relevant for resumable stops. Throw it away for now. - Fix an issue where a build could pass even if the final step failed. - `phlog()` exceptions so they show up in `bin/harbormaster` and the daemon logs. - Write an exception log if a step fails. - Add a "throw an exception" step to debug this stuff more easily. Test Plan: - Grepped for `checkForCancellation()`. - Ran a failing build where the final step caused the failure. - Observed `phlog()` in `bin/harbormaster` output. - Observed log in web UI: {F101168} Reviewers: btrahan, hach-que Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7935
2014-01-13 21:21:49 +01:00
'HarbormasterThrowExceptionBuildStep' => 'applications/harbormaster/step/HarbormasterThrowExceptionBuildStep.php',
Render build status on revisions and commits Summary: This uses an event listener to render the status of builds on their buildables. The revision and commit view now renders out the status of each of the builds. Currently the revision controller has the results for the latest diff rendered out. We might want to show the status of previous diffs in the future, but for now I think the latest diff should do fine. There's also a number of bug fixes in this diff, including a particularly nasty one where builds would have a build plan PHID generated for them, which resulted in handle lookups always returning invalid objects. Test Plan: Ran builds against diffs and commits, saw them appear on the revision and commit view controllers. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7544
2013-11-10 00:02:07 +01:00
'HarbormasterUIEventListener' => 'applications/harbormaster/event/HarbormasterUIEventListener.php',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterUploadArtifactBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterUploadArtifactBuildStepImplementation.php',
'HarbormasterWaitForPreviousBuildStepImplementation' => 'applications/harbormaster/step/HarbormasterWaitForPreviousBuildStepImplementation.php',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterWorker' => 'applications/harbormaster/worker/HarbormasterWorker.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldAction' => 'applications/herald/storage/HeraldAction.php',
Make Herald adapters provide content types Summary: Ref T2769. Get content types out of hard-coded config and into dynamic adapters. This removes the "MERGE" and "OWNERS" content types, which were vestigal. These needs are likely better addressed through subscriptions/transactions, and are obsolete, and haven't existed for 2+ years and no one has asked for them to be restored. Test Plan: Mostly a bunch of grep. Viewed rule list, rule edit. Edited a revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6656
2013-08-02 17:55:13 +02:00
'HeraldAdapter' => 'applications/herald/adapter/HeraldAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/HeraldApplyTranscript.php',
Move Herald application capabilities to newer infrastructure Summary: Ref T603. Use the new hotness. Test Plan: Edited Herald in Applications, tried to create rules / global rules without capabilities, got reasonable error messages. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7263
2013-10-09 22:44:41 +02:00
'HeraldCapabilityManageGlobalRules' => 'applications/herald/capability/HeraldCapabilityManageGlobalRules.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldCommitAdapter' => 'applications/herald/adapter/HeraldCommitAdapter.php',
'HeraldCondition' => 'applications/herald/storage/HeraldCondition.php',
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/HeraldConditionTranscript.php',
'HeraldController' => 'applications/herald/controller/HeraldController.php',
'HeraldDAO' => 'applications/herald/storage/HeraldDAO.php',
'HeraldDifferentialRevisionAdapter' => 'applications/herald/adapter/HeraldDifferentialRevisionAdapter.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldDisableController' => 'applications/herald/controller/HeraldDisableController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldEditLogQuery' => 'applications/herald/query/HeraldEditLogQuery.php',
'HeraldEffect' => 'applications/herald/engine/HeraldEffect.php',
'HeraldEngine' => 'applications/herald/engine/HeraldEngine.php',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldInvalidActionException' => 'applications/herald/engine/exception/HeraldInvalidActionException.php',
'HeraldInvalidConditionException' => 'applications/herald/engine/exception/HeraldInvalidConditionException.php',
'HeraldInvalidFieldException' => 'applications/herald/engine/exception/HeraldInvalidFieldException.php',
Add herald support for Maniphest Summary: standing on the shoulders of the badass work to move Maniphest to ApplicationTransactions, this diff implements a few methods and adds an adapter class. For now, we can add cc and flag tasks. I figure see what people ask for? Ref T1368. Test Plan: created herald rules for title and description text hits. made tasks and verified CC and flags worked. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T1368, T1638 Differential Revision: https://secure.phabricator.com/D7122
2013-09-25 20:50:15 +02:00
'HeraldManiphestTaskAdapter' => 'applications/herald/adapter/HeraldManiphestTaskAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldNewController' => 'applications/herald/controller/HeraldNewController.php',
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/HeraldObjectTranscript.php',
Add PHIDs to Herald Rules Summary: Ref T2769. Precursor to various Herald-related modernizations. Test Plan: Ran migration; loaded Herald via web. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6648
2013-08-02 15:11:25 +02:00
'HeraldPHIDTypeRule' => 'applications/herald/phid/HeraldPHIDTypeRule.php',
Integrate Pholio with Herald Summary: Ref T2766. Does the integration via ApplicationTransactionsEditor. Only did addCC and Flag for proof of concept. Test Plan: Made a rule to cc, made a rule to flag. They worked! (will attach screens to diff) Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2766 Differential Revision: https://secure.phabricator.com/D6766
2013-08-15 22:10:45 +02:00
'HeraldPholioMockAdapter' => 'applications/herald/adapter/HeraldPholioMockAdapter.php',
Allow Herald pre-commit rules to act on repository projects Summary: Fixes T4264. Adds: - New "Repository's projects" field to Herald pre-commit rules, so you can write global rules which act based on projects. - Allows pre-ref/pre-content rules to bind to projects, and fire for all repositories in that project, so users with limited power can write rules which apply to many repositories. - The pre-ref and pre-content classes were starting to share a fair amount of code, so I made them both extend an abstract base class. Test Plan: Wrote new pre-ref and pre-content rules bound to projects, then pushed commits into repositories in those projects and not in those projects. The "repository projects" field populated, and the rules fired for repositories in the relevant projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4264 Differential Revision: https://secure.phabricator.com/D7883
2014-01-03 21:24:28 +01:00
'HeraldPreCommitAdapter' => 'applications/diffusion/herald/HeraldPreCommitAdapter.php',
Provide basic commit content hooks for Herald Summary: Ref T4195. This doesn't provide any interesting fields yet (content, affected paths, commit message) but fires the hook correctly. Test Plan: Added a blocking hook and saw it fire. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7789
2013-12-18 23:18:45 +01:00
'HeraldPreCommitContentAdapter' => 'applications/diffusion/herald/HeraldPreCommitContentAdapter.php',
Add Herald support for blocking ref changes Summary: Ref T4195. Allows users to write Herald rules which block ref changes. For example, you can write a rule like `alincoln can not create branches`, or `no one can push to the branch "frozen"`. Test Plan: This covers a lot of ground. I created and pushed a bunch of rules, then looked at transcripts, in general. Here are some bits in detail: Here's a hook-based reject message: >>> orbital ~/repos/POEMS $ git push Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 274 bytes, done. Total 3 (delta 2), reused 0 (delta 0) remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: This commit was rejected by Herald pre-commit rule H24. remote: Rule: No Branches Called Blarp remote: Reason: "blarp" is a bad branch name remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp -> blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Here's a transcript, showing that all the field values populate sensibly: {F90453} Here's a rule: {F90454} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7782
2013-12-18 00:23:55 +01:00
'HeraldPreCommitRefAdapter' => 'applications/diffusion/herald/HeraldPreCommitRefAdapter.php',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldRecursiveConditionsException' => 'applications/herald/engine/exception/HeraldRecursiveConditionsException.php',
Give Herald rules a standard "Hnnn" object name Summary: Allow Herald rules to be referred to with `H123`, etc., like other object types are. Herald rules now have proper PHIDs and an increasingly prominent role in triggering application actions. Although I suspect users will rarely use `H123` in Remarkup to mention rules, this can simplify some of the interfaces which relate objects across systems. Test Plan: Looked at various interfaces and saw `H123` names. Mentioned `H123` in remarkup. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7786
2013-12-18 21:00:18 +01:00
'HeraldRemarkupRule' => 'applications/herald/remarkup/HeraldRemarkupRule.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/HeraldRepetitionPolicyConfig.php',
'HeraldRule' => 'applications/herald/storage/HeraldRule.php',
'HeraldRuleController' => 'applications/herald/controller/HeraldRuleController.php',
'HeraldRuleEdit' => 'applications/herald/storage/HeraldRuleEdit.php',
'HeraldRuleEditHistoryController' => 'applications/herald/controller/HeraldRuleEditHistoryController.php',
'HeraldRuleEditHistoryView' => 'applications/herald/view/HeraldRuleEditHistoryView.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldRuleEditor' => 'applications/herald/editor/HeraldRuleEditor.php',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleListController' => 'applications/herald/controller/HeraldRuleListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRuleQuery' => 'applications/herald/query/HeraldRuleQuery.php',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleSearchEngine' => 'applications/herald/query/HeraldRuleSearchEngine.php',
Add ApplicationTransactions to Herald Summary: Ref T2769. I'm planning to keep this pretty simple, but we have this ad-hoc edit log for rules already and some other mess that we can clean up. Test Plan: No effect yet; see future changes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6654
2013-08-02 17:28:55 +02:00
'HeraldRuleTransaction' => 'applications/herald/storage/HeraldRuleTransaction.php',
'HeraldRuleTransactionComment' => 'applications/herald/storage/HeraldRuleTransactionComment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/HeraldRuleTranscript.php',
'HeraldRuleTypeConfig' => 'applications/herald/config/HeraldRuleTypeConfig.php',
Add a normal "view" page for Herald rules Summary: Ref T2769. This will house the transaction list and replace the "edit log" stuff. The UI is a little bit rough and can probably share more code with the transaction history, but seems mostly-reasonable. Test Plan: {F53253} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6690
2013-08-06 22:43:45 +02:00
'HeraldRuleViewController' => 'applications/herald/controller/HeraldRuleViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTestConsoleController' => 'applications/herald/controller/HeraldTestConsoleController.php',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldTransactionQuery' => 'applications/herald/query/HeraldTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTranscript' => 'applications/herald/storage/transcript/HeraldTranscript.php',
'HeraldTranscriptController' => 'applications/herald/controller/HeraldTranscriptController.php',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'HeraldTranscriptGarbageCollector' => 'applications/herald/garbagecollector/HeraldTranscriptGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'HeraldTranscriptListController' => 'applications/herald/controller/HeraldTranscriptListController.php',
Make Herald transcripts policy-aware Summary: Ref T603. Herald transcripts potentially leak a bunch of content (task text, revision/commit content). Don't let users see them if they can't see the actual objects. This is a little messy but ends up mostly reasonable-ish. Test Plan: - Verified that transcripts for objects I couldn't see no longer appear in the list, and reject access. - Verified that transcripts for objects in applications I can't see reject access, albeit less gracefully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7221
2013-10-05 00:17:18 +02:00
'HeraldTranscriptQuery' => 'applications/herald/query/HeraldTranscriptQuery.php',
Herald - add application search for transcripts Summary: this diff also makes the "test console" appear with the main search nav *and* updates application search to use the page title as the crumb rather than just search. Fixes T4399. Test Plan: queried for transcript ids - success! queried for TX and MX - success! saved the TX and MX query and it worked again! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4399 Differential Revision: https://secure.phabricator.com/D8297
2014-02-21 21:51:25 +01:00
'HeraldTranscriptSearchEngine' => 'applications/herald/query/HeraldTranscriptSearchEngine.php',
Truncate object fields in Herald transcripts Summary: A few users have hit cases where Herald transcripts of large commits exceed the MySQL packet limit, because one of the fields in the transcript is an enomrous textual diff. There's no value in saving these huge amounts of data. Transcripts are useful for understanding the action of Herald rules, but can be reconstructed later. Instead of saving all of the data, limit each field to 4KB of data. For strings, we just truncate at 4KB. For arrays, we truncate after 4KB of values. Test Plan: Ran unit tests. Artificially decreased limit and ran transcripts, saw them truncate properly. Reviewers: btrahan Reviewed By: btrahan CC: frgtn, aran Differential Revision: https://secure.phabricator.com/D7783
2013-12-18 20:59:53 +01:00
'HeraldTranscriptTestCase' => 'applications/herald/storage/__tests__/HeraldTranscriptTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Javelin' => 'infrastructure/javelin/Javelin.php',
'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',
Allow configuration of default document policies for Legalpad Summary: Ref T3116. User request / generally modern feature. Test Plan: Set defaults to whacky projects and created a new document; it defaulted appropriately. Reviewers: btrahan Reviewed By: btrahan CC: aran, allan.laal Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D8110
2014-01-30 20:47:42 +01:00
'LegalpadCapabilityDefaultEdit' => 'applications/legalpad/capability/LegalpadCapabilityDefaultEdit.php',
'LegalpadCapabilityDefaultView' => 'applications/legalpad/capability/LegalpadCapabilityDefaultView.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadConstants' => 'applications/legalpad/constants/LegalpadConstants.php',
'LegalpadController' => 'applications/legalpad/controller/LegalpadController.php',
'LegalpadDAO' => 'applications/legalpad/storage/LegalpadDAO.php',
'LegalpadDocument' => 'applications/legalpad/storage/LegalpadDocument.php',
'LegalpadDocumentBody' => 'applications/legalpad/storage/LegalpadDocumentBody.php',
'LegalpadDocumentCommentController' => 'applications/legalpad/controller/LegalpadDocumentCommentController.php',
'LegalpadDocumentEditController' => 'applications/legalpad/controller/LegalpadDocumentEditController.php',
'LegalpadDocumentEditor' => 'applications/legalpad/editor/LegalpadDocumentEditor.php',
'LegalpadDocumentListController' => 'applications/legalpad/controller/LegalpadDocumentListController.php',
'LegalpadDocumentQuery' => 'applications/legalpad/query/LegalpadDocumentQuery.php',
Legalpad - remarkup LX to link to LX Summary: standard ish. Fixes T4388. Test Plan: made a comment with L1 and noted L1 linked to L1. Also observed working-ish hovercard. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4388 Differential Revision: https://secure.phabricator.com/D8178
2014-02-10 20:27:08 +01:00
'LegalpadDocumentRemarkupRule' => 'applications/legalpad/remarkup/LegalpadDocumentRemarkupRule.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSearchEngine' => 'applications/legalpad/query/LegalpadDocumentSearchEngine.php',
Legalpad - add signature page Summary: Fixes T3481. Sort of - this thing be very ugly. Also it assumes that you'll "always" want to sign terms. I was thinking in a future diff that should be optional as well as configurable, though it was unclear to me if either was worth pursuing... Generally very hideous as the three main elements (PHUIDocument, AphrontErrorView, and AphrontForm with an AphrontFormInset) have never really played together before. Test Plan: agreed to some test terms. noted UI displayed nicely. reloaded and noted UI told me I had signed it already. Went to different terms and filled them out wrong and got sensical errors. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3481 Differential Revision: https://secure.phabricator.com/D6399
2013-07-10 20:46:39 +02:00
'LegalpadDocumentSignController' => 'applications/legalpad/controller/LegalpadDocumentSignController.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSignature' => 'applications/legalpad/storage/LegalpadDocumentSignature.php',
Legalpad - add a view signatures page Summary: ...needs to add a LegalpadDocumentSignatureQuery class to get this done, which is also re-deployed everywhere we were issuing raw queries. Ref T3116. Test Plan: viewed some signatures. Verified color and footer icons showed up how I wanted them to. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7986
2014-01-17 20:40:26 +01:00
'LegalpadDocumentSignatureListController' => 'applications/legalpad/controller/LegalpadDocumentSignatureListController.php',
'LegalpadDocumentSignatureQuery' => 'applications/legalpad/query/LegalpadDocumentSignatureQuery.php',
Legalpad - make it work for not logged in users Summary: Adds "verified" and "secretKey" to Legalpad document signatures. For logged in users using an email address they own, things are verified right away. Otherwise, the email is sent a verification letter. When the user clicks the link the signature is marked verified. Test Plan: signed the document with a bogus email address not logged in. verified the email that would be sent looked good from command line. followed link and successfully verified bogus email address Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, asherkin Maniphest Tasks: T4283 Differential Revision: https://secure.phabricator.com/D7930
2014-01-15 02:17:18 +01:00
'LegalpadDocumentSignatureVerificationController' => 'applications/legalpad/controller/LegalpadDocumentSignatureVerificationController.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentViewController' => 'applications/legalpad/controller/LegalpadDocumentViewController.php',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'LegalpadMockMailReceiver' => 'applications/legalpad/mail/LegalpadMockMailReceiver.php',
'LegalpadReplyHandler' => 'applications/legalpad/mail/LegalpadReplyHandler.php',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadTransaction' => 'applications/legalpad/storage/LegalpadTransaction.php',
'LegalpadTransactionComment' => 'applications/legalpad/storage/LegalpadTransactionComment.php',
'LegalpadTransactionQuery' => 'applications/legalpad/query/LegalpadTransactionQuery.php',
'LegalpadTransactionType' => 'applications/legalpad/constants/LegalpadTransactionType.php',
'LegalpadTransactionView' => 'applications/legalpad/view/LegalpadTransactionView.php',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'infrastructure/storage/lisk/__tests__/LiskChunkTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskDAO' => 'infrastructure/storage/lisk/LiskDAO.php',
'LiskDAOSet' => 'infrastructure/storage/lisk/LiskDAOSet.php',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'infrastructure/storage/lisk/__tests__/LiskDAOTestCase.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'LiskEphemeralObjectException' => 'infrastructure/storage/lisk/LiskEphemeralObjectException.php',
'LiskFixtureTestCase' => 'infrastructure/storage/lisk/__tests__/LiskFixtureTestCase.php',
'LiskIsolationTestCase' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestCase.php',
'LiskIsolationTestDAO' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAO.php',
'LiskIsolationTestDAOException' => 'infrastructure/storage/lisk/__tests__/LiskIsolationTestDAOException.php',
Add an iterator to make it easier to perform database migrations Summary: See D3006, D3007. Make it easier to do migrations like that without holding all results in memory. Test Plan: Ran this code with an artificially small page size (2): foreach (new LiskMigrationIterator(new DifferentialRevision()) as $rev) { echo "Revision ".$rev->getID()."\n"; } Verified each revision as loaded and processed. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1162 Differential Revision: https://secure.phabricator.com/D3008
2012-07-19 05:01:23 +02:00
'LiskMigrationIterator' => 'infrastructure/storage/lisk/LiskMigrationIterator.php',
Add LiskRawMigrationIterator Summary: Ref T2222. I need this to migrate the Differential comment tables, because they are large. We have the similar `LiskMigrationIterator` already, but it won't work here because I intend to destroy the original objects after migrating them. Test Plan: Wrote a script to iterate over the `differential_comment` table, got reasonable output: {P869} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6264
2013-06-21 21:55:07 +02:00
'LiskRawMigrationIterator' => 'infrastructure/storage/lisk/LiskRawMigrationIterator.php',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ManiphestActionMenuEventListener' => 'applications/maniphest/event/ManiphestActionMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestBatchEditController' => 'applications/maniphest/controller/ManiphestBatchEditController.php',
Add capabilities for editing task triage details (priority, assignee, etc) Summary: This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions. Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces. Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
'ManiphestCapabilityBulkEdit' => 'applications/maniphest/capability/ManiphestCapabilityBulkEdit.php',
Add defualt view and default edit policies for tasks Summary: Ref T603. Allow global default policies to be configured for tasks. Test Plan: - Created task via web UI. - Created task via Conduit. - Created task via email. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7267
2013-10-09 22:53:17 +02:00
'ManiphestCapabilityDefaultEdit' => 'applications/maniphest/capability/ManiphestCapabilityDefaultEdit.php',
'ManiphestCapabilityDefaultView' => 'applications/maniphest/capability/ManiphestCapabilityDefaultView.php',
Add capabilities for editing task triage details (priority, assignee, etc) Summary: This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions. Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces. Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
'ManiphestCapabilityEditAssign' => 'applications/maniphest/capability/ManiphestCapabilityEditAssign.php',
'ManiphestCapabilityEditPolicies' => 'applications/maniphest/capability/ManiphestCapabilityEditPolicies.php',
'ManiphestCapabilityEditPriority' => 'applications/maniphest/capability/ManiphestCapabilityEditPriority.php',
'ManiphestCapabilityEditProjects' => 'applications/maniphest/capability/ManiphestCapabilityEditProjects.php',
'ManiphestCapabilityEditStatus' => 'applications/maniphest/capability/ManiphestCapabilityEditStatus.php',
Convert maniphest to use standard fields Summary: Ref T3794. Drop auxiliary field, use standard field. Test Plan: Performed migration, field seemed to survive it intact. Edited and viewed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794 Differential Revision: https://secure.phabricator.com/D7036
2013-09-19 20:56:15 +02:00
'ManiphestConfiguredCustomField' => 'applications/maniphest/field/ManiphestConfiguredCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestConstants' => 'applications/maniphest/constants/ManiphestConstants.php',
'ManiphestController' => 'applications/maniphest/controller/ManiphestController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestCreateMailReceiver' => 'applications/maniphest/mail/ManiphestCreateMailReceiver.php',
Make Maniphest custom fields extend PhabricatorCustomField Summary: Ref T418. These implementations share no method names, so we can safely just move Maniphest fields into the `PhabricatorCustomField` hierarchy. Replaces two Maniphest-specific custom field exceptions which nothing catches. Test Plan: Viewed Maniphest, edited/altered custom fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6927
2013-09-11 00:31:48 +02:00
'ManiphestCustomField' => 'applications/maniphest/field/ManiphestCustomField.php',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldNumericIndex' => 'applications/maniphest/storage/ManiphestCustomFieldNumericIndex.php',
Bring "fixes x as y" parser forward and use new parsers instead of old ones Summary: Fixes T3872. Ref T1812. Ref T3886. Modernize the "closes x as y" string parser, and use all the new parsers instead of the old ones. Test Plan: Made a commit full of a pile of these trigger strings, then used `scripts/repository/reparse.php --message` to reparse it. Verified that parses came back as expected using a bunch of `var_dump()`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1812, T3872, T3886 Differential Revision: https://secure.phabricator.com/D8263
2014-02-18 00:59:13 +01:00
'ManiphestCustomFieldStatusParser' => 'applications/maniphest/field/parser/ManiphestCustomFieldStatusParser.php',
'ManiphestCustomFieldStatusParserTestCase' => 'applications/maniphest/field/parser/__tests__/ManiphestCustomFieldStatusParserTestCase.php',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldStorage' => 'applications/maniphest/storage/ManiphestCustomFieldStorage.php',
'ManiphestCustomFieldStringIndex' => 'applications/maniphest/storage/ManiphestCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestDAO' => 'applications/maniphest/storage/ManiphestDAO.php',
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',
Provide and populate an object name index for Maniphest Summary: See discussion in D6955. This provides a table we can JOIN against to (effectively) "ORDER BY project name", populates it intially, and keeps it up to date as projects are edited. Test Plan: - Ran storage upgrade, verified projects populated into the table. - Edited a project, verified its entry updated. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6957
2013-09-12 22:06:44 +02:00
'ManiphestNameIndex' => 'applications/maniphest/storage/ManiphestNameIndex.php',
'ManiphestNameIndexEventListener' => 'applications/maniphest/event/ManiphestNameIndexEventListener.php',
Use Application PHIDs in Maniphest Summary: Ref T2715. Switch Maniphest to the new stuff. Test Plan: Used `phid.query`; `phid.lookup` to load objects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6516
2013-07-21 21:05:28 +02:00
'ManiphestPHIDTypeTask' => 'applications/maniphest/phid/ManiphestPHIDTypeTask.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',
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',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'ManiphestStatusConfigOptionType' => 'applications/maniphest/config/ManiphestStatusConfigOptionType.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'ManiphestTaskDescriptionPreviewController' => 'applications/maniphest/controller/ManiphestTaskDescriptionPreviewController.php',
'ManiphestTaskDetailController' => 'applications/maniphest/controller/ManiphestTaskDetailController.php',
'ManiphestTaskEditController' => 'applications/maniphest/controller/ManiphestTaskEditController.php',
Rename `ManiphestTaskListControllerPro` to `ManiphestTaskListController` Summary: This marks the first time in history that "Pro" has been removed. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6980
2013-09-13 18:50:46 +02:00
'ManiphestTaskListController' => 'applications/maniphest/controller/ManiphestTaskListController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskListView' => 'applications/maniphest/view/ManiphestTaskListView.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ManiphestTaskMailReceiver' => 'applications/maniphest/mail/ManiphestTaskMailReceiver.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move ManiphestTaskQuery into query/ Summary: Move this into a more consistent location. Test Plan: Loaded Maniphest. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6949
2013-09-12 22:02:55 +02:00
'ManiphestTaskQuery' => 'applications/maniphest/query/ManiphestTaskQuery.php',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskResultListView' => 'applications/maniphest/view/ManiphestTaskResultListView.php',
Introduce ManiphestTaskSearchEngine plus ManiphestTaskListControllerPro Summary: Ref T603. Ref T2625. Cutting this over is tricky because of Maniphest's existing saved queries. Plan here is: - Build out the "pro" controller at `/maniphest/query/`. - Once it's at parity, migrate custom queries. - Nuke the old UI. This provides a minimal implementation with no filter support. Test Plan: Looked at `/maniphest/query/`, saw results technically available. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6933
2013-09-10 19:04:26 +02:00
'ManiphestTaskSearchEngine' => 'applications/maniphest/query/ManiphestTaskSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskStatus' => 'applications/maniphest/constants/ManiphestTaskStatus.php',
Add config validation for task status config Summary: Ref T1812. This still doesn't expose configuration to the user, but adds validation for it. Test Plan: Added a pile of unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8584
2014-03-25 22:04:51 +01:00
'ManiphestTaskStatusTestCase' => 'applications/maniphest/constants/__tests__/ManiphestTaskStatusTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTaskSubscriber' => 'applications/maniphest/storage/ManiphestTaskSubscriber.php',
Rename ManiphestTransactionPro -> ManiphestTransaction Summary: Ref T2217. Pro is the new standard. Test Plan: Lots of `grep`, made a pile of Maniphest views/edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7093
2013-09-24 19:49:06 +02:00
'ManiphestTransaction' => 'applications/maniphest/storage/ManiphestTransaction.php',
Route all ManiphestTransaction reads through a single class Summary: Ref T2217. I'm going to do the fake-double-writes ("double reads"?) thing where we proxy the storage that worked pretty well for auth. That is: - (Some more cleanup diffs next, maybe?) - Move all the data to the new storage, and make `ManiphestTransaction` read and write by wrapping `ManiphestTransactionPro`. - If nothing breaks, it's a straight shot to nuking ManiphestTransaction callsite by callsite. I think Maniphest is way easier than Differential, because there are very few query sites and no inline comments. Test Plan: `grep` to find callsites. Loaded task view, called Conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7067
2013-09-23 23:25:14 +02:00
'ManiphestTransactionComment' => 'applications/maniphest/storage/ManiphestTransactionComment.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTransactionEditor' => 'applications/maniphest/editor/ManiphestTransactionEditor.php',
'ManiphestTransactionPreviewController' => 'applications/maniphest/controller/ManiphestTransactionPreviewController.php',
Migrate all Maniphest transaction data to new storage Summary: Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except: - The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so: - When migrating, "edit" + "comment" transactions need to be split in two. - When editing now, we should no longer combine these transaction types. - These changes are pretty straightforward and low-impact. - This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though. Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other. Test Plan: - Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly. - Droped the test data and performed the migration. - Looked at the resulting data for obvious discrepancies. - Looked at a bunch of tasks and their transaction history. - Used Conduit to pull transaction data. - Edited task description and clicked "View Details" on transaction. - Used batch editor. - Made a bunch more edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 23:25:28 +02:00
'ManiphestTransactionQuery' => 'applications/maniphest/query/ManiphestTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'ManiphestTransactionSaveController' => 'applications/maniphest/controller/ManiphestTransactionSaveController.php',
'ManiphestView' => 'applications/maniphest/view/ManiphestView.php',
'MetaMTAConstants' => 'applications/metamta/constants/MetaMTAConstants.php',
Add a GC for sent and received mail Summary: Ref T4368. We don't currently GC these tables, and the sent mail table is one of the largest on `secure.phabricator.com`. There's no value in retaining this information indefinitely. Instead, retain it for 90 days, which should be plenty of time to debug/diagnose any issues. Test Plan: Ran `phd debug garbage`, saw it clean up a reasonable amount of data from these tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8127
2014-02-03 19:51:31 +01:00
'MetaMTAMailReceivedGarbageCollector' => 'applications/metamta/garbagecollector/MetaMTAMailReceivedGarbageCollector.php',
'MetaMTAMailSentGarbageCollector' => 'applications/metamta/garbagecollector/MetaMTAMailSentGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
Naunce - capalities for Source object Summary: another little piece here that basically just adds some permissions to source editing. serving it up before I do anything too complicated to make sure it seems kosher. in terms of what comes next this form needs to be dynamic based on source type so there'll be some fun there. That said, I plan to implement a more simple "phabricator form" only version to start here and flesh out a few other things like queues with that. Test Plan: set permission to no one for source edit and got a nice error page. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7535
2013-11-08 21:45:14 +01:00
'NuanceCapabilitySourceDefaultEdit' => 'applications/nuance/capability/NuanceCapabilitySourceDefaultEdit.php',
'NuanceCapabilitySourceDefaultView' => 'applications/nuance/capability/NuanceCapabilitySourceDefaultView.php',
'NuanceCapabilitySourceManage' => 'applications/nuance/capability/NuanceCapabilitySourceManage.php',
'NuanceConstants' => 'applications/nuance/constants/NuanceConstants.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceController' => 'applications/nuance/controller/NuanceController.php',
'NuanceDAO' => 'applications/nuance/storage/NuanceDAO.php',
'NuanceItem' => 'applications/nuance/storage/NuanceItem.php',
'NuanceItemEditController' => 'applications/nuance/controller/NuanceItemEditController.php',
'NuanceItemEditor' => 'applications/nuance/editor/NuanceItemEditor.php',
'NuanceItemQuery' => 'applications/nuance/query/NuanceItemQuery.php',
'NuanceItemTransaction' => 'applications/nuance/storage/NuanceItemTransaction.php',
'NuanceItemTransactionComment' => 'applications/nuance/storage/NuanceItemTransactionComment.php',
'NuanceItemTransactionQuery' => 'applications/nuance/query/NuanceItemTransactionQuery.php',
'NuanceItemViewController' => 'applications/nuance/controller/NuanceItemViewController.php',
'NuancePHIDTypeItem' => 'applications/nuance/phid/NuancePHIDTypeItem.php',
'NuancePHIDTypeQueue' => 'applications/nuance/phid/NuancePHIDTypeQueue.php',
'NuancePHIDTypeRequestor' => 'applications/nuance/phid/NuancePHIDTypeRequestor.php',
'NuancePHIDTypeSource' => 'applications/nuance/phid/NuancePHIDTypeSource.php',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuancePhabricatorFormSourceDefinition' => 'applications/nuance/source/NuancePhabricatorFormSourceDefinition.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQuery' => 'applications/nuance/query/NuanceQuery.php',
'NuanceQueue' => 'applications/nuance/storage/NuanceQueue.php',
'NuanceQueueEditController' => 'applications/nuance/controller/NuanceQueueEditController.php',
'NuanceQueueEditor' => 'applications/nuance/editor/NuanceQueueEditor.php',
'NuanceQueueItem' => 'applications/nuance/storage/NuanceQueueItem.php',
'NuanceQueueQuery' => 'applications/nuance/query/NuanceQueueQuery.php',
'NuanceQueueTransaction' => 'applications/nuance/storage/NuanceQueueTransaction.php',
'NuanceQueueTransactionComment' => 'applications/nuance/storage/NuanceQueueTransactionComment.php',
'NuanceQueueTransactionQuery' => 'applications/nuance/query/NuanceQueueTransactionQuery.php',
'NuanceQueueViewController' => 'applications/nuance/controller/NuanceQueueViewController.php',
'NuanceRequestor' => 'applications/nuance/storage/NuanceRequestor.php',
'NuanceRequestorEditController' => 'applications/nuance/controller/NuanceRequestorEditController.php',
'NuanceRequestorEditor' => 'applications/nuance/editor/NuanceRequestorEditor.php',
'NuanceRequestorQuery' => 'applications/nuance/query/NuanceRequestorQuery.php',
'NuanceRequestorSource' => 'applications/nuance/storage/NuanceRequestorSource.php',
'NuanceRequestorTransaction' => 'applications/nuance/storage/NuanceRequestorTransaction.php',
'NuanceRequestorTransactionComment' => 'applications/nuance/storage/NuanceRequestorTransactionComment.php',
'NuanceRequestorTransactionQuery' => 'applications/nuance/query/NuanceRequestorTransactionQuery.php',
'NuanceRequestorViewController' => 'applications/nuance/controller/NuanceRequestorViewController.php',
'NuanceSource' => 'applications/nuance/storage/NuanceSource.php',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuanceSourceDefinition' => 'applications/nuance/source/NuanceSourceDefinition.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceEditController' => 'applications/nuance/controller/NuanceSourceEditController.php',
'NuanceSourceEditor' => 'applications/nuance/editor/NuanceSourceEditor.php',
'NuanceSourceQuery' => 'applications/nuance/query/NuanceSourceQuery.php',
'NuanceSourceTransaction' => 'applications/nuance/storage/NuanceSourceTransaction.php',
'NuanceSourceTransactionComment' => 'applications/nuance/storage/NuanceSourceTransactionComment.php',
'NuanceSourceTransactionQuery' => 'applications/nuance/query/NuanceSourceTransactionQuery.php',
'NuanceSourceViewController' => 'applications/nuance/controller/NuanceSourceViewController.php',
'NuanceTransaction' => 'applications/nuance/storage/NuanceTransaction.php',
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',
PHUIButtonBarView Summary: Adds a handy bar full of tiny buttons. Use only when directed. Ref: T4394 Test Plan: View UI Examples. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8169
2014-02-10 20:11:36 +01:00
'PHUIButtonBarExample' => 'applications/uiexample/examples/PHUIButtonBarExample.php',
'PHUIButtonBarView' => 'view/phui/PHUIButtonBarView.php',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'applications/uiexample/examples/PHUIButtonExample.php',
'PHUIButtonView' => 'view/phui/PHUIButtonView.php',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PHUICalendarListView' => 'view/phui/calendar/PHUICalendarListView.php',
'PHUICalendarMonthView' => 'view/phui/calendar/PHUICalendarMonthView.php',
'PHUICalendarWidgetView' => 'view/phui/calendar/PHUICalendarWidgetView.php',
Color Palette Summary: Picked a set of standard colors. Based on our current Maniphest color set, but tweaked to the same hue with http://color.hailpixel.com/ Test Plan: Not intended to be end all be all, but a decent first cut. Applied to Maniphest and Tags. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6229
2013-06-19 00:35:14 +02:00
'PHUIColorPalletteExample' => 'applications/uiexample/examples/PHUIColorPalletteExample.php',
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',
Update Form Layouts Summary: This attempts some consistency in form layouts. Notably, they all now contain headers and are 16px off the sides and tops of pages. Also updated dialogs to the same look and feel. I think I got 98% of forms with this pass, but it's likely I missed some buried somewhere. TODO: will take another pass as consolidating these colors and new gradients in another diff. Test Plan: Played in my sandbox all week. Please play with it too and let me know how they feel. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6806
2013-08-26 20:53:11 +02:00
'PHUIFormLayoutView' => 'view/form/PHUIFormLayoutView.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'view/form/control/PHUIFormMultiSubmitControl.php',
'PHUIFormPageView' => 'view/form/PHUIFormPageView.php',
Policy, Status in PHUIHeaderView Summary: The adds the ability to set 'properties' such as state, privacy, due date to the header of objects. Test Plan: Implemented in Paste, Pholio. Tested various states. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7016
2013-09-17 18:12:37 +02:00
'PHUIHeaderView' => 'view/phui/PHUIHeaderView.php',
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',
PHUIInfoPanel Summary: First cut of an 'info panel' for phabricator. Basic concept is for display a list of items with a bit more info and depth and an object item list. Projects could be a good first example. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7398
2013-10-25 20:09:06 +02:00
'PHUIInfoPanelExample' => 'applications/uiexample/examples/PHUIInfoPanelExample.php',
'PHUIInfoPanelView' => 'view/phui/PHUIInfoPanelView.php',
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',
Move PHUIFormBoxView to PHUIObjectBoxView Summary: I'd like to reuse this for other content areas, renaming for now. This might be weird to keep setForm, but I can fix that later if we need. Test Plan: reload a few forms in maniphest, projects, differential Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7120
2013-09-25 20:23:29 +02:00
'PHUIObjectBoxView' => 'view/phui/PHUIObjectBoxView.php',
Move PhabricatorObjectItem to PHUIObjectItem, add 'plain' setting for lists. Summary: Adds plain support for object lists that just look like lists Test Plan: review UIexamples and a number of other applications Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6922
2013-09-09 23:14:34 +02:00
'PHUIObjectItemListExample' => 'applications/uiexample/examples/PHUIObjectItemListExample.php',
'PHUIObjectItemListView' => 'view/phui/PHUIObjectItemListView.php',
'PHUIObjectItemView' => 'view/phui/PHUIObjectItemView.php',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIPagedFormView' => 'view/form/PHUIPagedFormView.php',
Update pinboard view styles, move to PHUI Summary: Tightens up the CSS to display more items (4 wide on 15") and fixes some mobile CSS issues with appseach. Fixes T3614 Test Plan: Tested Pholio, Macros, mobile layouts Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3614 Differential Revision: https://secure.phabricator.com/D6694
2013-08-07 19:58:09 +02:00
'PHUIPinboardItemView' => 'view/phui/PHUIPinboardItemView.php',
'PHUIPinboardView' => 'view/phui/PHUIPinboardView.php',
PHUIPropertyListView Summary: This builds out and implements PHUIPropertyListView (container) and PHUIPropertyListItemView (section) as well as adding tabs. Test Plan: Tested each page I edited with the exception of Releeph and Phortune, though those changes look ok to me diff wise. Updated examples page with tabs. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7283
2013-10-11 16:53:56 +02:00
'PHUIPropertyGroupView' => 'view/phui/PHUIPropertyGroupView.php',
'PHUIPropertyListExample' => 'applications/uiexample/examples/PHUIPropertyListExample.php',
'PHUIPropertyListView' => 'view/phui/PHUIPropertyListView.php',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PHUIRemarkupPreviewPanel' => 'view/phui/PHUIRemarkupPreviewPanel.php',
Add PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PHUIStatusItemView' => 'view/phui/PHUIStatusItemView.php',
'PHUIStatusListView' => 'view/phui/PHUIStatusListView.php',
Move PhabricatorTagView to PHUITagView Summary: For consistency and great justice. Test Plan: tested audit, uiexamples, action headers Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7967
2014-01-14 23:09:52 +01:00
'PHUITagExample' => 'applications/uiexample/examples/PHUITagExample.php',
'PHUITagView' => 'view/phui/PHUITagView.php',
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',
PHUITimelineView Summary: Updates PhabricatorTimeline to PHUITimeline. Uses standard colors and spacing, softens up the actors, and reduces visual spacing of action-only events. - Also updated some 2x sprite images. Test Plan: Tested Tasks Paste and Pholio in my sandbox. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8205
2014-02-12 18:02:05 +01:00
'PHUITimelineEventView' => 'view/phui/PHUITimelineEventView.php',
'PHUITimelineExample' => 'applications/uiexample/examples/PHUITimelineExample.php',
'PHUITimelineView' => 'view/phui/PHUITimelineView.php',
Move Workboards to PHUI Summary: This is just renaming to PHUI (I like shorter text :) Test Plan: reload workboard examples page, seems to not fatal and looks very appealing Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6904
2013-09-06 23:06:12 +02:00
'PHUIWorkboardExample' => 'applications/uiexample/examples/PHUIWorkboardExample.php',
'PHUIWorkboardView' => 'view/phui/PHUIWorkboardView.php',
'PHUIWorkpanelView' => 'view/phui/PHUIWorkpanelView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseAbstractKey' => 'applications/passphrase/keys/PassphraseAbstractKey.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseController' => 'applications/passphrase/controller/PassphraseController.php',
'PassphraseCredential' => 'applications/passphrase/storage/PassphraseCredential.php',
Add a credential selection control to Passphrase Summary: Ref T4122. Adds a control for choosing credentials. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran, lsave Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7617
2013-11-21 21:35:36 +01:00
'PassphraseCredentialControl' => 'applications/passphrase/view/PassphraseCredentialControl.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialCreateController' => 'applications/passphrase/controller/PassphraseCredentialCreateController.php',
'PassphraseCredentialDestroyController' => 'applications/passphrase/controller/PassphraseCredentialDestroyController.php',
'PassphraseCredentialEditController' => 'applications/passphrase/controller/PassphraseCredentialEditController.php',
'PassphraseCredentialListController' => 'applications/passphrase/controller/PassphraseCredentialListController.php',
Add a "Lock Permanently" action to Passphrase Summary: Fixes T4931. Each new credential should come with the ability to lock the credential permanently, so that no one can ever edit again. Each existing credential must allow user to lock existing credential. Test Plan: Create new credential, verify that you can lock it before saving it. Open existing unlocked credential, verify that option to lock it exists. Once credential is locked, the option to reveal it should be disabled, and editing the credential won't allow username/password updates. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4931 Differential Revision: https://secure.phabricator.com/D8947
2014-05-03 03:05:19 +02:00
'PassphraseCredentialLockController' => 'applications/passphrase/controller/PassphraseCredentialLockController.php',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialPublicController' => 'applications/passphrase/controller/PassphraseCredentialPublicController.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialQuery' => 'applications/passphrase/query/PassphraseCredentialQuery.php',
'PassphraseCredentialRevealController' => 'applications/passphrase/controller/PassphraseCredentialRevealController.php',
'PassphraseCredentialSearchEngine' => 'applications/passphrase/query/PassphraseCredentialSearchEngine.php',
'PassphraseCredentialTransaction' => 'applications/passphrase/storage/PassphraseCredentialTransaction.php',
'PassphraseCredentialTransactionEditor' => 'applications/passphrase/editor/PassphraseCredentialTransactionEditor.php',
'PassphraseCredentialTransactionQuery' => 'applications/passphrase/query/PassphraseCredentialTransactionQuery.php',
'PassphraseCredentialType' => 'applications/passphrase/credentialtype/PassphraseCredentialType.php',
'PassphraseCredentialTypePassword' => 'applications/passphrase/credentialtype/PassphraseCredentialTypePassword.php',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialTypeSSHGeneratedKey' => 'applications/passphrase/credentialtype/PassphraseCredentialTypeSSHGeneratedKey.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialTypeSSHPrivateKey' => 'applications/passphrase/credentialtype/PassphraseCredentialTypeSSHPrivateKey.php',
'PassphraseCredentialTypeSSHPrivateKeyFile' => 'applications/passphrase/credentialtype/PassphraseCredentialTypeSSHPrivateKeyFile.php',
'PassphraseCredentialTypeSSHPrivateKeyText' => 'applications/passphrase/credentialtype/PassphraseCredentialTypeSSHPrivateKeyText.php',
'PassphraseCredentialViewController' => 'applications/passphrase/controller/PassphraseCredentialViewController.php',
'PassphraseDAO' => 'applications/passphrase/storage/PassphraseDAO.php',
'PassphrasePHIDTypeCredential' => 'applications/passphrase/phid/PassphrasePHIDTypeCredential.php',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphrasePasswordKey' => 'applications/passphrase/keys/PassphrasePasswordKey.php',
'PassphraseSSHKey' => 'applications/passphrase/keys/PassphraseSSHKey.php',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseSecret' => 'applications/passphrase/storage/PassphraseSecret.php',
Modernize policies in Paste and Macro Summary: Ref T603. Fixes T2823. This updates Paste and Macro. - **Paste** - Added default view policy. - I didn't add a "create" policy, since I can't come up with any realistic scenario where you'd give users access to pastes but not let them create them. - **Macro** - Added a "manage" policy, which covers creating and editing macros. This lets an install only allow "People With An Approved Sense of Humor" or whatever to create macros. - Removed the "edit" policy, since giving individual users access to specific macros doesn't make much sense to me. - Changed the view policy to the "most public" policy the install allows. - Added view policy information to the header. Also fix a couple of minor things in Maniphest. Test Plan: - Set Paste policy, created pastes via web and Conduit, saw they got the right default policies. - Set Macro policy, tried to create/edit macros with valid and unauthorized users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2823, T603 Differential Revision: https://secure.phabricator.com/D7317
2013-10-16 19:35:52 +02:00
'PasteCapabilityDefaultView' => 'applications/paste/capability/PasteCapabilityDefaultView.php',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PasteCreateMailReceiver' => 'applications/paste/mail/PasteCreateMailReceiver.php',
Paste 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',
Paste - add support for email replies and subscribers Summary: Email replies and subscribers seem to go hand in hand so deploy both at once. Test Plan: played around with bin/mail. Verified replies posted comments on the paste. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3650 Differential Revision: https://secure.phabricator.com/D6682
2013-08-06 02:11:46 +02:00
'PasteMockMailReceiver' => 'applications/paste/mail/PasteMockMailReceiver.php',
'PasteReplyHandler' => 'applications/paste/mail/PasteReplyHandler.php',
Add a granular capability for user directory browsing Summary: Fixes T4358. User request from IRC, but I think this is generally reasonable. Although we can not prevent users from determining that other user accounts exist in the general case, it does seem reasonable to restrict browsing the user directory to a subset of users. In our case, I'll probably do this on `secure.phabricator.com`, since it seems a little odd to let Google index the user directory, for example. Test Plan: Set the policy to "no one" and tried to browse users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4358 Differential Revision: https://secure.phabricator.com/D8112
2014-01-30 20:53:49 +01:00
'PeopleCapabilityBrowseUserDirectory' => 'applications/people/capability/PeopleCapabilityBrowseUserDirectory.php',
Add a GC for user logs Summary: Fixes T4368. This is the last "obvious" table we have which we should be GC'ing but do not. It's about 1/12th of the data on `secure.phabricator.com`. This table stores logins, account creation, password resets, login attempts, etc, and is primarily useful if something sketchy happens so you can go back and review login activity. This data is not useful indefinitely, and there's no reason to retain it forever. Because you don't always know when something sketchy happened I've given this table a fairly long TTL (180 days), but we don't need limitless amounts of this data. Test Plan: Ran `phd debug garbage` and saw a reasonable amount of data get GC'd. This table already has an appropriate key. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8128
2014-02-03 19:51:41 +01:00
'PeopleUserLogGarbageCollector' => 'applications/people/garbagecollector/PeopleUserLogGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'Phabricator404Controller' => 'applications/base/controller/Phabricator404Controller.php',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'applications/config/option/PhabricatorAWSConfigOptions.php',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorAccessControlTestCase' => 'applications/base/controller/__tests__/PhabricatorAccessControlTestCase.php',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorAccessLog' => 'infrastructure/log/PhabricatorAccessLog.php',
Add "Developer" and "Access Log" config option groups, some types Summary: - Add a "developer" option group. - Add an "access log" option group. - Render the types "bool", "int" and "string" in a more tailored way. - Add a config check for dead config. Right now this serves as a "TODO" list of things that need to be migrated. Test Plan: Looked at config options, setup issues. Edited bool, int, string options. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4308
2013-01-01 23:09:17 +01:00
'PhabricatorAccessLogConfigOptions' => 'applications/config/option/PhabricatorAccessLogConfigOptions.php',
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',
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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorAllCapsTranslation' => 'infrastructure/internationalization/translation/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',
Add a `./bin/aphlict build` workflow. Summary: Currently, it is a bit tricky to build the Aphlict client SWF from the ActionScript source. Provide a `./bin/aphlict build` workflow that simplifies this process. Depends on D9226. Test Plan: Executed the workflow: ``` > ./bin/aphlict build Done. ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9338
2014-06-07 20:33:55 +02:00
'PhabricatorAphlictManagementBuildWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementBuildWorkflow.php',
Make `./bin/aphlict` behave more like a service. Summary: Fixes T5126. Provide `start`, `stop`, `restart`, `debug` and `status` workflows for `./bin/aphlict`. This makes it easier to manage Aphlict as if it were a service. Test Plan: ``` > sudo ./bin/aphlict status Aphlict is not running. > sudo ./bin/aphlict stop Aphlict is not running. > sudo ./bin/aphlict start Aphlict Server started. > sudo ./bin/aphlict status Aphlict (12880) is running. > sudo ./bin/aphlict restart Stopping Aphlict Server (12880)... Aphlict Server (12880) exited normally. Aphlict Server started. > sudo ./bin/aphlict stop Stopping Aphlict Server (12895)... Aphlict Server (12895) exited normally. > sudo ./bin/aphlict debug Starting Aphlict server in foreground... Launching server: $ node '/usr/src/phabricator/src/applications/aphlict/management/../../../../support/aphlict/server/aphlict_server.js' --port='22280' --admin='22281' --host='localhost' --user='aphlict' [Fri May 30 2014 09:56:14 GMT+0000 (UTC)] Started Server (PID 12911) ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5126 Differential Revision: https://secure.phabricator.com/D9226
2014-06-05 21:13:44 +02:00
'PhabricatorAphlictManagementDebugWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementDebugWorkflow.php',
'PhabricatorAphlictManagementRestartWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementRestartWorkflow.php',
'PhabricatorAphlictManagementStartWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStartWorkflow.php',
'PhabricatorAphlictManagementStatusWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStatusWorkflow.php',
'PhabricatorAphlictManagementStopWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementStopWorkflow.php',
'PhabricatorAphlictManagementWorkflow' => 'applications/aphlict/management/PhabricatorAphlictManagementWorkflow.php',
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',
Provide hasChildren() to replace isEmptyContent() Summary: Fixes T3698. Sometimes views need to render differently depending on whether they contain content or not. The existing approach for this is `isEmptyContent()`, which doesn't work well and is sort of hacky (it implies double-rendering content, which is not always free or side-effect free). Instead, provide a test for an element without children. This test is powerful enough to catch the easy cases of `null`, etc., and just do the expected thing, but will not catch a View which is reduced upon rendering. Since this is rare and we have no actual need for it today, just accept that as a limitation. Test Plan: Viewed Timeline and Feed UI examples. Viewed Feed (feed), Pholio (timelineview), and Differential (old transactionview). {F53915} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3698 Differential Revision: https://secure.phabricator.com/D6718
2013-08-12 16:51:01 +02:00
'PhabricatorAphrontViewTestCase' => 'view/__tests__/PhabricatorAphrontViewTestCase.php',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorAppSearchEngine' => 'applications/meta/query/PhabricatorAppSearchEngine.php',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorApplication' => 'applications/base/PhabricatorApplication.php',
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',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorApplicationDashboard' => 'applications/dashboard/application/PhabricatorApplicationDashboard.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 remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'PhabricatorApplicationDoorkeeper' => 'applications/doorkeeper/application/PhabricatorApplicationDoorkeeper.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 application policies to be edited Summary: Ref T603. Enables: - Application policies can be edited. - Applications can define custom policies (this will be used for setting defaults, like "what is the default visibiltiy of new tasks", and meta-policies, like "who can create a task?"). Test Plan: Edited application policies. A future diff does more with custom policies. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7205
2013-10-03 21:40:08 +02:00
'PhabricatorApplicationEditController' => 'applications/meta/controller/PhabricatorApplicationEditController.php',
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',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'PhabricatorApplicationHarbormaster' => 'applications/harbormaster/application/PhabricatorApplicationHarbormaster.php',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorApplicationHelp' => 'applications/help/application/PhabricatorApplicationHelp.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',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorApplicationHome' => 'applications/home/application/PhabricatorApplicationHome.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',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'PhabricatorApplicationLegalpad' => 'applications/legalpad/application/PhabricatorApplicationLegalpad.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',
Slightly modernize Aphlict server status page Summary: Ref T4324. Add a real `Application` class. Use modern UI elements. @chad, we could use an icon :3 Test Plan: {F114477} Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8254
2014-02-18 01:00:19 +01:00
'PhabricatorApplicationNotifications' => 'applications/notification/application/PhabricatorApplicationNotifications.php',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'PhabricatorApplicationNuance' => 'applications/nuance/application/PhabricatorApplicationNuance.php',
Fix an anchor redirect issue with OAuth server, plus modernize the application a bit Summary: Ref T4593. Via HackerOne. An attacker can use the anchor reattachment, combined with the Facebook token workflow, combined with redirection on OAuth errors to capture access tokens. The attack works roughly like this: - Create an OAuth application on Phabricator. - Set the domain to `evil.com`. - Grab the OAuth URI for it (something like `https://phabricator.com/oauthserver/auth/?redirect_uri=http://evil.com&...`). - Add an invalid `scope` parameter (`scope=xyz`). - Use //that// URI to build a Facebook OAuth URI (something like `https://facebook.com/oauth/?redirect_uri=http://phabricator.com/...&response_type=token`). - After the user authorizes the application on Facebook (or instantly if they've already authorized it), they're redirected to the OAuth server, which processes the request. Since this is the 'token' workflow, it has auth information in the URL anchor/fragment. - The OAuth server notices the `scope` error and 302's to the attacker's domain, preserving the anchor in most browsers through anchor reattachment. - The attacker reads the anchor in JS and can do client workflow stuff. To fix this, I've made several general changes/modernizations: - Add a new application and make it beta. This is mostly cleanup, but also turns the server off for typical installs (it's not generally useful quite yet). - Add a "Console" page to make it easier to navigate. - Modernize some of the UI, since I was touching most of it anyways. Then I've made specific security-focused changes: - In the web-based OAuth workflow, send back a human-readable page when errors occur. I //think// this is universally correct. Previously, humans would get a blob of JSON if they entered an invalid URI, etc. This type of response is correct for the companion endpoint ("ServerTokenController") since it's called by programs, but I believe not correct for this endpoint ("AuthController") since it's used by humans. Most of this is general cleanup (give humans human-readable errors instead of JSON blobs). - Never 302 off this endpoint automatically. Previously, a small set of errors (notably, bad `scope`) would cause a 302 with 'error'. This exposes us to anchor reattachment, and isn't generally helpful to anyone, since the requesting application did something wrong and even if it's prepared to handle the error, it can't really do anything better than we can. - The only time we'll 'error' back now from this workflow is if a user explicitly cancels the workflow. This isn't a 302, but a normal link (the cancel button), so the anchor is lost. - Even if the application is already approved, don't blindly 302. Instead, show the user a confirmation dialog with a 'continue' link. This is perhaps slightly less user-friendly than the straight redirect, but I think it's pretty reasonable in general, and it gives us a lot of protection against these classes of attack. This redirect is then through a link, not a 302, so the anchor is again detached. - Test Plan: I attempted to hit everything I touched. See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4593 Differential Revision: https://secure.phabricator.com/D8517
2014-03-13 20:59:10 +01:00
'PhabricatorApplicationOAuthServer' => 'applications/oauthserver/application/PhabricatorApplicationOAuthServer.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',
Add more application query capabilities Summary: Make the application query a little more flexible, and formalize the PHID type. Test Plan: See next diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7201
2013-10-03 21:39:15 +02:00
'PhabricatorApplicationPHIDTypeApplication' => 'applications/meta/phid/PhabricatorApplicationPHIDTypeApplication.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',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PhabricatorApplicationPassphrase' => 'applications/passphrase/application/PhabricatorApplicationPassphrase.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',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhabricatorApplicationPhragment' => 'applications/phragment/application/PhabricatorApplicationPhragment.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',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorApplicationPolicy' => 'applications/policy/application/PhabricatorApplicationPolicy.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',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorApplicationQuery' => 'applications/meta/query/PhabricatorApplicationQuery.php',
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',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorApplicationSupport' => 'applications/support/application/PhabricatorApplicationSupport.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorApplicationSystem' => 'applications/system/application/PhabricatorApplicationSystem.php',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorApplicationTest' => 'applications/base/controller/__tests__/PhabricatorApplicationTest.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 a quote action to Differential and Maniphest Summary: Ref T4119. This is ugly for now, but technically works. The comment area and transaction log don't realy know about each other, so for the moment the linking is a bit manual. Differential/Maniphest are special cases anyway. Test Plan: {F149992} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4119 Differential Revision: https://secure.phabricator.com/D8957
2014-05-05 19:55:58 +02:00
'PhabricatorApplicationTransactionCommentQuoteController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentQuoteController.php',
Allow users to remove their own comments, and administrators to remove any comment Summary: Fixes T4909. Adds a "remove" link next to the edit link, which permanently hides a comment. Addresses two use cases: - Allowing administrators to clean up spam. - Allowing users to try to put the genie back in the bottle if they post passwords or sensitive links, etc. The user who removed the comment is named in the removal text to enforce some level of administrative accountability. No data is deleted, but there's currently no method to restore these comments. We'll see if we need one. This is cheating a little bit by storing "removed" as "2" in the isDeleted field. This doesn't seem tooooo bad for now. Test Plan: - Removed some of my comments. - As an administrator, removed other users' comments. - Failed to view history of a removed comment. - Failed to edit a removed comment. - Failed to remove a removed comment. - Verified feed doesn't show the old comment after comment removal. Reviewers: btrahan Reviewed By: btrahan Subscribers: qgil, chad, epriestley Maniphest Tasks: T4909 Differential Revision: https://secure.phabricator.com/D8945
2014-05-05 19:55:32 +02:00
'PhabricatorApplicationTransactionCommentRemoveController' => 'applications/transactions/controller/PhabricatorApplicationTransactionCommentRemoveController.php',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'applications/transactions/view/PhabricatorApplicationTransactionCommentView.php',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'applications/transactions/controller/PhabricatorApplicationTransactionController.php',
Transactions - make the details stuff generic and ajaxy Summary: Fixes T2213 Test Plan: Updated a pholio mock description. Observed that when I first showed details there was a round trip made. Toggled show / hide noting no more trips made to server. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D6801
2013-08-23 01:45:14 +02:00
'PhabricatorApplicationTransactionDetailController' => 'applications/transactions/controller/PhabricatorApplicationTransactionDetailController.php',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'applications/transactions/editor/PhabricatorApplicationTransactionEditor.php',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'applications/transactions/feed/PhabricatorApplicationTransactionFeedStory.php',
Integrate subscriptions with ApplicationTransactions Summary: Fixes T2214. For objects which support ApplicationTransaction, use ApplicationTransactions to apply subscription action changes. Principally, this makes clicking "Subscribe" / "Unsubscribe" appear correctly in the transaction log. Test Plan: Clicked "Subscribe" and "Unsubscribe" a on Macros and Mocks. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T2214 Differential Revision: https://secure.phabricator.com/D4986
2013-02-17 15:37:09 +01:00
'PhabricatorApplicationTransactionInterface' => 'applications/transactions/interface/PhabricatorApplicationTransactionInterface.php',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'applications/transactions/exception/PhabricatorApplicationTransactionNoEffectException.php',
'PhabricatorApplicationTransactionNoEffectResponse' => 'applications/transactions/response/PhabricatorApplicationTransactionNoEffectResponse.php',
Use application PHIDs for application transactions Summary: Ref T2715. Ref T3578. Load application transactions through application PHID infrastructure. Test Plan: Viewed feed, saw successful loads of application transaction objects and rendered feed stories. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6617
2013-07-29 15:51:19 +02:00
'PhabricatorApplicationTransactionPHIDTypeTransaction' => 'applications/transactions/phid/PhabricatorApplicationTransactionPHIDTypeTransaction.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',
Improve ApplicationTransaction behavior for poorly constructed transactions Summary: Ref T2222. Five very small improvements: - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable. - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value. - Add an additional check for the other case (shouldn't have a value, but does). - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong. - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions. Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4557, T2222 Differential Revision: https://secure.phabricator.com/D8401
2014-03-05 19:44:21 +01:00
'PhabricatorApplicationTransactionStructureException' => 'applications/transactions/exception/PhabricatorApplicationTransactionStructureException.php',
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',
Allow custom fields to have validation logic Summary: Ref T418. This is fairly messy, but basically: - Add a validation phase to TransactionEditor. - Add a validation phase to CustomField. - Bring it to StandardField. - Add validation logic for the int field. - Provide support in related classes. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7028
2013-09-19 00:31:58 +02:00
'PhabricatorApplicationTransactionValidationError' => 'applications/transactions/error/PhabricatorApplicationTransactionValidationError.php',
'PhabricatorApplicationTransactionValidationException' => 'applications/transactions/exception/PhabricatorApplicationTransactionValidationException.php',
Policy Transactions - add a details view for custom policy Summary: 'cuz those can be complicated. Fixes T4738. I needed to do a fair amount of heavy lifting to get the policy stuff rendering correctly. For now, I made this end point very one purpose and tried to make that clear. Test Plan: looked at some custom policies. see screenshots. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4738 Differential Revision: https://secure.phabricator.com/D8890
2014-04-29 18:42:54 +02:00
'PhabricatorApplicationTransactionValueController' => 'applications/transactions/controller/PhabricatorApplicationTransactionValueController.php',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'applications/transactions/view/PhabricatorApplicationTransactionView.php',
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',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorApplicationTypeahead' => 'applications/typeahead/application/PhabricatorApplicationTypeahead.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',
Initial Asana sync for Differential Summary: Ref T2852. This is highly incomplete but seems structurally sound. Some additional context is available in the Google doc. - Add a workspace ID configuration. Without it, nothing else activates. - Add a worker which reacts to feed stories. - Feed stories about things which aren't Differential objects are ignored. - We load the revision, or fail permanently if we can't. - We get all the related user PHIDs (author, reviewers, CCs). - We check if any of them have linked Asana accounts, or fail permanently if they don't. - We check for an "ASANATASK" edge from the revision. - If we do not find one, we create a new task. - If we do find one, we load the task. - If we succeed, we check the chronological key of the most recent synchronized feed story ("cursor"). - If this story is the same or newer, we update the task to synchronize it to the current state of the revision. - If we fail to load the task, we fail permanently ("asana task has been deleted"). - We then publish the actual story text to the task. Not in yet: - Updating followers requires separate API calls which we don't do yet. - No subtasks yet. - No sync of open/closed state. Test Plan: {F47546} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6302
2013-06-26 01:33:16 +02:00
'PhabricatorAsanaConfigOptions' => 'applications/doorkeeper/option/PhabricatorAsanaConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'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',
Provide a more flexible script for administrative management of audits Summary: Fixes T3679. This comes up every so often and the old script is extremely broad (nuke everything in a repository). Provide a more surgical tool. Test Plan: Ran a bunch of variations of the script and they all seemed to work OK. Reviewers: btrahan Reviewed By: btrahan CC: aran, staticshock Maniphest Tasks: T3679 Differential Revision: https://secure.phabricator.com/D6678
2013-08-05 19:35:01 +02:00
'PhabricatorAuditManagementDeleteWorkflow' => 'applications/audit/management/PhabricatorAuditManagementDeleteWorkflow.php',
'PhabricatorAuditManagementWorkflow' => 'applications/audit/management/PhabricatorAuditManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditPreviewController' => 'applications/audit/controller/PhabricatorAuditPreviewController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditReplyHandler' => 'applications/audit/mail/PhabricatorAuditReplyHandler.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/PhabricatorAuditStatusConstants.php',
Show account cards for external accounts on "linked accounts" screen and "link new account" Summary: Ref T1536. These can probably use some design tweaking and there's a bit of a bug with profile images for some providers, but generally seems to be in the right ballpark. Test Plan: {F46604} {F46605} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6210
2013-06-17 16:08:50 +02:00
'PhabricatorAuthAccountView' => 'applications/auth/view/PhabricatorAuthAccountView.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthConfirmLinkController' => 'applications/auth/controller/PhabricatorAuthConfirmLinkController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorAuthController' => 'applications/auth/controller/PhabricatorAuthController.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthDAO' => 'applications/auth/storage/PhabricatorAuthDAO.php',
Allow AuthenticationProviderConfig to be enabled and disabled Summary: Ref T1536. Nothing too exciting here, one TODO about tailoring error messages. Test Plan: {F46403} {F46404} {F46405} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6204
2013-06-17 19:54:08 +02:00
'PhabricatorAuthDisableController' => 'applications/auth/controller/config/PhabricatorAuthDisableController.php',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthDowngradeSessionController' => 'applications/auth/controller/PhabricatorAuthDowngradeSessionController.php',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthEditController' => 'applications/auth/controller/config/PhabricatorAuthEditController.php',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthFactor' => 'applications/auth/factor/PhabricatorAuthFactor.php',
'PhabricatorAuthFactorConfig' => 'applications/auth/storage/PhabricatorAuthFactorConfig.php',
'PhabricatorAuthFactorTOTP' => 'applications/auth/factor/PhabricatorAuthFactorTOTP.php',
'PhabricatorAuthFactorTOTPTestCase' => 'applications/auth/factor/__tests__/PhabricatorAuthFactorTOTPTestCase.php',
Require multiple auth factors to establish web sessions Summary: Ref T4398. This prompts users for multi-factor auth on login. Roughly, this introduces the idea of "partial" sessions, which we haven't finished constructing yet. In practice, this means the session has made it through primary auth but not through multi-factor auth. Add a workflow for bringing a partial session up to a full one. Test Plan: - Used Conduit. - Logged in as multi-factor user. - Logged in as no-factor user. - Tried to do non-login-things with a partial session. - Reviewed account activity logs. {F149295} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8922
2014-05-01 19:23:02 +02:00
'PhabricatorAuthFinishController' => 'applications/auth/controller/PhabricatorAuthFinishController.php',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthHighSecurityRequiredException' => 'applications/auth/exception/PhabricatorAuthHighSecurityRequiredException.php',
'PhabricatorAuthHighSecurityToken' => 'applications/auth/data/PhabricatorAuthHighSecurityToken.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthLinkController' => 'applications/auth/controller/PhabricatorAuthLinkController.php',
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthListController' => 'applications/auth/controller/config/PhabricatorAuthListController.php',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'applications/auth/controller/PhabricatorAuthLoginController.php',
Provide `bin/auth ldap` for LDAP diagnostics Summary: Ref T1536. Test Plan: Ran `bin/auth ldap`. Reviewers: mbishopim3, chad Reviewed By: mbishopim3 CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6218
2013-06-17 22:26:25 +02:00
'PhabricatorAuthManagementLDAPWorkflow' => 'applications/auth/management/PhabricatorAuthManagementLDAPWorkflow.php',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementListFactorsWorkflow' => 'applications/auth/management/PhabricatorAuthManagementListFactorsWorkflow.php',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementRecoverWorkflow' => 'applications/auth/management/PhabricatorAuthManagementRecoverWorkflow.php',
Add `bin/auth refresh` for debugging OAuth token refresh issues Summary: Ref T2852. Provide a script for inspecting/debugging OAuth token refresh. Test Plan: Ran `bin/auth refresh` with various arguments, saw token refreshes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6276
2013-06-25 00:55:41 +02:00
'PhabricatorAuthManagementRefreshWorkflow' => 'applications/auth/management/PhabricatorAuthManagementRefreshWorkflow.php',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementStripWorkflow' => 'applications/auth/management/PhabricatorAuthManagementStripWorkflow.php',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementWorkflow' => 'applications/auth/management/PhabricatorAuthManagementWorkflow.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorAuthNeedsApprovalController' => 'applications/auth/controller/PhabricatorAuthNeedsApprovalController.php',
Allow installs to require multi-factor authentication for all users Summary: Ref T5089. Adds a `security.require-multi-factor-auth` which forces all users to enroll in MFA before they can use their accounts. Test Plan: Config: {F159750} Roadblock: {F159748} After configuration: {F159749} - Required MFA, got roadblocked, added MFA, got unblocked. - Removed MFA, got blocked again. - Used `bin/auth strip` to strip MFA, got blocked. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5089 Differential Revision: https://secure.phabricator.com/D9285
2014-06-04 01:50:27 +02:00
'PhabricatorAuthNeedsMultiFactorController' => 'applications/auth/controller/PhabricatorAuthNeedsMultiFactorController.php',
Add initial create screen for auth providers Summary: Ref T1536. Adds an initial "choose a provider type" screen for adding a new provider. This doesn't go anywhere yet. Test Plan: {F46316} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6199
2013-06-17 19:51:35 +02:00
'PhabricatorAuthNewController' => 'applications/auth/controller/config/PhabricatorAuthNewController.php',
Send old login code to the bottom of the sea Summary: Ref T1536. This is extremely reachable and changes the login code to the new stuff. Notes: - I've hard-disabled password registration since I want installs to explicitly flip it on via config if they want it. New installs will get it by default in the future, but old installs shouldn't have their auth options change. - Google doesn't let us change the redirect URI, so keep the old one working. - We need to keep a bit of LDAP around for now for LDAP import. - **Facebook:** This causes substantive changes in what login code is executed. Test Plan: - Logged in / logged out / registered, hit new flows. - Logged in with google. - Verified no password registration by default. Reviewers: btrahan, chad Reviewed By: chad CC: wez, nh, aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6222
2013-06-19 10:33:27 +02:00
'PhabricatorAuthOldOAuthRedirectController' => 'applications/auth/controller/PhabricatorAuthOldOAuthRedirectController.php',
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
'PhabricatorAuthOneTimeLoginController' => 'applications/auth/controller/PhabricatorAuthOneTimeLoginController.php',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthPHIDTypeAuthFactor' => 'applications/auth/phid/PhabricatorAuthPHIDTypeAuthFactor.php',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthProvider' => 'applications/auth/provider/PhabricatorAuthProvider.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfig' => 'applications/auth/storage/PhabricatorAuthProviderConfig.php',
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthProviderConfigController' => 'applications/auth/controller/config/PhabricatorAuthProviderConfigController.php',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthProviderConfigEditor' => 'applications/auth/editor/PhabricatorAuthProviderConfigEditor.php',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigQuery' => 'applications/auth/query/PhabricatorAuthProviderConfigQuery.php',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfigTransaction' => 'applications/auth/storage/PhabricatorAuthProviderConfigTransaction.php',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigTransactionQuery' => 'applications/auth/query/PhabricatorAuthProviderConfigTransactionQuery.php',
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 Twitter as an authentication provider Summary: Ref T3687. Depends on D6864. Implements the `OAuth1` provider in Phabricator (which is mostly similar to the OAuth2 provider, but doesn't share quite enough code to actually extend a common base class, I think) and Twitter as a concrete subclass. Test Plan: Created a Twitter provider. Registered, logged in, linked, refreshed account link. {F57054} {F57056} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6865
2013-09-03 14:53:08 +02:00
'PhabricatorAuthProviderOAuth1' => 'applications/auth/provider/PhabricatorAuthProviderOAuth1.php',
Add JIRA as an authentication provider Summary: Ref T3687. Depends on D6867. This allows login/registration through JIRA. The notable difference between this and other providers is that we need to do configuration in two stages, since we need to generate and save a public/private keypair before we can give the user configuration instructions, which takes several seconds and can't change once we've told them to do it. To this effect, the edit form renders two separate stages, a "setup" stage and a "configure" stage. In the setup stage the user identifies the install and provides the URL. They hit save, we generate a keypair, and take them to the configure stage. In the configure stage, they're walked through setting up all the keys. This ends up feeling a touch rough, but overall pretty reasonable, and we haven't lost much generality. Test Plan: {F57059} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6868
2013-09-03 14:53:21 +02:00
'PhabricatorAuthProviderOAuth1JIRA' => 'applications/auth/provider/PhabricatorAuthProviderOAuth1JIRA.php',
Add Twitter as an authentication provider Summary: Ref T3687. Depends on D6864. Implements the `OAuth1` provider in Phabricator (which is mostly similar to the OAuth2 provider, but doesn't share quite enough code to actually extend a common base class, I think) and Twitter as a concrete subclass. Test Plan: Created a Twitter provider. Registered, logged in, linked, refreshed account link. {F57054} {F57056} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6865
2013-09-03 14:53:08 +02:00
'PhabricatorAuthProviderOAuth1Twitter' => 'applications/auth/provider/PhabricatorAuthProviderOAuth1Twitter.php',
OAuth - add a little notes section for admins to remember details about external accounts Summary: Fixes T4755. This also includes putting in a note that Google might ToS you to use the Google+ API. Lots of code here as there was some repeated stuff between OAuth1 and OAuth2 so I made a base OAuth with less-base OAuth1 and OAuth2 inheriting from it. The JIRA provider remains an independent mess and didn't get the notes field thing. Test Plan: looked at providers and read pretty instructions. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4755 Differential Revision: https://secure.phabricator.com/D8726
2014-04-09 20:09:50 +02:00
'PhabricatorAuthProviderOAuth2' => 'applications/auth/provider/PhabricatorAuthProviderOAuth2.php',
Add Amazon and Asana providers Summary: Ref T1536. Ref T2852. Adds providers for Asana and Amazon. See D6248. Test Plan: {F46960} {F46961} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T1536, T2852 Differential Revision: https://secure.phabricator.com/D6249
2013-06-20 20:19:11 +02:00
'PhabricatorAuthProviderOAuthAmazon' => 'applications/auth/provider/PhabricatorAuthProviderOAuthAmazon.php',
'PhabricatorAuthProviderOAuthAsana' => 'applications/auth/provider/PhabricatorAuthProviderOAuthAsana.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',
Support Twitch.tv as an OAuth provider Summary: This is mostly for personal reasons / lols, but they have a perfectly functional OAuth2 API and it takes like 15 minutes to add a provider now and I was in this code anyway... @chad, we could use JIRA, Twitter and Twitch.tv auth icons if you have a chance. Test Plan: {F53564} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6706
2013-08-08 22:34:30 +02:00
'PhabricatorAuthProviderOAuthTwitch' => 'applications/auth/provider/PhabricatorAuthProviderOAuthTwitch.php',
WordPress.com OAuth2 plugin Summary: This plugin provides an OAuth authentication provider to authenticate users using WordPress.com Connect. This diff corresponds to github pull request https://github.com/facebook/phabricator/pull/593/ and had its libphutil counterpart reviewed in D9004. Test Plan: Configured WordPress.com as an authentication provider, saw it show up on the login screen, registered a new account, got expected defaults for my username/name/email/profile picture. Reviewers: chad, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9019
2014-05-08 23:23:12 +02:00
'PhabricatorAuthProviderOAuthWordPress' => 'applications/auth/provider/PhabricatorAuthProviderOAuthWordPress.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',
Add Persona auth provider Summary: Ref T3958. Adds a provider for Mozilla's Persona auth. Test Plan: - Created a Persona provider. - Registered a new account with Persona. - Logged in with Persona. - Linked an account with Persona. - Dissolved an account link with Persona. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3958 Differential Revision: https://secure.phabricator.com/D7313
2013-10-14 23:34:57 +02:00
'PhabricatorAuthProviderPersona' => 'applications/auth/provider/PhabricatorAuthProviderPersona.php',
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 19:13:49 +02:00
'PhabricatorAuthRegisterController' => 'applications/auth/controller/PhabricatorAuthRegisterController.php',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSession' => 'applications/auth/storage/PhabricatorAuthSession.php',
Separate session management from PhabricatorUser Summary: Ref T4310. Ref T3720. Session operations are currently part of PhabricatorUser. This is more tightly coupled than needbe, and makes it difficult to establish login sessions for non-users. Move all the session management code to a `SessionEngine`. Test Plan: - Viewed sessions. - Regenerated Conduit certificate. - Verified Conduit sessions were destroyed. - Logged out. - Logged in. - Ran conduit commands. - Viewed sessions again. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7962
2014-01-14 22:22:27 +01:00
'PhabricatorAuthSessionEngine' => 'applications/auth/engine/PhabricatorAuthSessionEngine.php',
Expire and garbage collect unused sessions Summary: Ref T3720. Ref T4310. Currently, we limit the maximum number of concurrent sessions of each type. This is primarily because sessions predate garbage collection and we had no way to prevent the session table from growing fairly quickly and without bound unless we did this. Now that we have GC (and it's modular!) we can just expire unused sessions after a while and throw them away: - Add a `sessionExpires` column to the table, with a key. - Add a GC for old sessions. - When we establish a session, set `sessionExpires` to the current time plus the session TTL. - When a user uses a session and has used up more than 20% of the time on it, extend the session. In addition to this, we could also rotate sessions, but I think that provides very little value. If we do want to implement it, we should hold it until after T3720 / T4310. Test Plan: - Ran schema changes. - Looked at database. - Tested GC: - Started GC. - Set expires on one row to the past. - Restarted GC. - Verified GC nuked the session. - Logged in. - Logged out. - Ran Conduit method. - Tested refresh: - Set threshold to 0.0001% instead of 20%. - Loaded page. - Saw a session extension ever few page loads. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7976
2014-01-15 22:56:16 +01:00
'PhabricatorAuthSessionGarbageCollector' => 'applications/auth/garbagecollector/PhabricatorAuthSessionGarbageCollector.php',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSessionQuery' => 'applications/auth/query/PhabricatorAuthSessionQuery.php',
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',
Add "temporary tokens" to auth, for SMS codes, TOTP codes, reset codes, etc Summary: Ref T4398. We have several auth-related systems which require (or are improved by) the ability to hand out one-time codes which expire after a short period of time. In particular, these are: - SMS multi-factor: we need to be able to hand out one-time codes for this in order to prove the user has the phone. - Password reset emails: we use a time-based rotating token right now, but we could improve this with a one-time token, so once you reset your password the link is dead. - TOTP auth: we don't need to verify/invalidate keys, but can improve security by doing so. This adds a generic one-time code storage table, and strengthens the TOTP enrollment process by using it. Specifically, you can no longer edit the enrollment form (the one with a QR code) to force your own key as the TOTP key: only keys Phabricator generated are accepted. This has no practical security impact, but generally helps raise the barrier potential attackers face. Followup changes will use this for reset emails, then implement SMS multi-factor. Test Plan: - Enrolled in TOTP multi-factor auth. - Submitted an error in the form, saw the same key presented. - Edited the form with web tools to provide a different key, saw it reject and the server generate an alternate. - Change the expiration to 5 seconds instead of 1 hour, submitted the form over and over again, saw it cycle the key after 5 seconds. - Looked at the database and saw the tokens I expected. - Ran the GC and saw all the 5-second expiry tokens get cleaned up. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9217
2014-05-20 20:43:45 +02:00
'PhabricatorAuthTemporaryToken' => 'applications/auth/storage/PhabricatorAuthTemporaryToken.php',
'PhabricatorAuthTemporaryTokenGarbageCollector' => 'applications/auth/garbagecollector/PhabricatorAuthTemporaryTokenGarbageCollector.php',
'PhabricatorAuthTemporaryTokenQuery' => 'applications/auth/query/PhabricatorAuthTemporaryTokenQuery.php',
Allow users to terminate login sessions Summary: This is partly a good feature, and partly should reduce false positives on HackerOne reporting things vaguely related to this. Allow a user to terminate login sessions from the settings panel. Test Plan: - Terminated a session. - Terminated all sessions. - Tried to terminate all sessions again. - Logged in with two browsers, terminated the other browser's session, reloaded, got kicked out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8556
2014-03-17 23:02:01 +01:00
'PhabricatorAuthTerminateSessionController' => 'applications/auth/controller/PhabricatorAuthTerminateSessionController.php',
Rate limit multi-factor actions Summary: Ref T4398. Prevent users from brute forcing multi-factor auth by rate limiting attempts. This slightly refines the rate limiting to allow callers to check for a rate limit without adding points, and gives users credit for successfully completing an auth workflow. Test Plan: Tried to enter hisec with bad credentials 11 times in a row, got rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8911
2014-04-30 23:30:31 +02:00
'PhabricatorAuthTryFactorAction' => 'applications/auth/action/PhabricatorAuthTryFactorAction.php',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthUnlinkController' => 'applications/auth/controller/PhabricatorAuthUnlinkController.php',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'applications/auth/controller/PhabricatorAuthValidateController.php',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'applications/config/option/PhabricatorAuthenticationConfigOptions.php',
Make it much easier to add one-off event listeners Summary: Ref T4657. Right now, you have to muck with `events.listeners` to install listeners. Instead, automatically install all subclasses of AutoEventListener. Primarily, this makes it easier to resolve requests with "drop this file in `src/extensions/`, no warranty", which seems to have worked well so far in resolving things like custom remarkup rules, etc. Test Plan: - Added such a listener, had it autoregister. - Clicked around and saw the effects of normal listeners. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4657 Differential Revision: https://secure.phabricator.com/D9262
2014-05-23 00:19:28 +02:00
'PhabricatorAutoEventListener' => 'infrastructure/events/PhabricatorAutoEventListener.php',
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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorBaseEnglishTranslation' => 'infrastructure/internationalization/translation/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',
Implement bcrypt hasher, transparent login upgrade, and explicit upgrade for passwords Summary: Ref T4443. - Add a `password_hash()`-based bcrypt hasher if `password_hash()` is available. - When a user logs in using a password, upgrade their password to the strongest available hash format. - On the password settings page: - Warn the user if their password uses any algorithm other than the strongest one. - Show the algorithm the password uses. - Show the best available algorithm. Test Plan: As an md5 user, viewed password settings page and saw a warning. Logged out. Logged in, got upgraded, no more warning. Changed password, verified database rehash. Logged out, logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8270
2014-02-18 20:03:56 +01:00
'PhabricatorBcryptPasswordHasher' => 'infrastructure/util/password/PhabricatorBcryptPasswordHasher.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorBot' => 'infrastructure/daemon/bot/PhabricatorBot.php',
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',
'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',
Fix full width form layouts Summary: Fixes T3473, mostly reverts previous changes to clean up required field text, will have to redesign that in general for responsiveness. Test Plan: use logout form, use new conpherence form Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3473 Differential Revision: https://secure.phabricator.com/D6371
2013-07-04 05:24:28 +02:00
'PhabricatorBusyExample' => 'applications/uiexample/examples/PhabricatorBusyExample.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'applications/cache/storage/PhabricatorCacheDAO.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheGeneralGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheGeneralGarbageCollector.php',
Provide 'bin/cache', for managing caches Summary: See <https://github.com/facebook/phabricator/issues/323>. We have a very old cache management script which doesn't purge all the modern caches (and does purge some caches which are no longer in use). Update it so it purges all the modern caches (remarkup, general, changeset), no longer purges outdated caches, and is easier to use. Also delete a lot of "this script has moved" scripts from the last few rounds of similar cleanup, I believe all of these have been in master for at least several months, which should be enough time for users to get used to the new stuff. Test Plan: Ran `bin/cache` with various arguments. Verified caches were purged. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5978
2013-05-20 19:16:35 +02:00
'PhabricatorCacheManagementPurgeWorkflow' => 'applications/cache/management/PhabricatorCacheManagementPurgeWorkflow.php',
'PhabricatorCacheManagementWorkflow' => 'applications/cache/management/PhabricatorCacheManagementWorkflow.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheMarkupGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheMarkupGarbageCollector.php',
'PhabricatorCacheTTLGarbageCollector' => 'applications/cache/garbagecollector/PhabricatorCacheTTLGarbageCollector.php',
Add a "setup" cache Summary: See T2062. This cache allows us to essentially implement this sort of block: if (this_code_has_not_run_since_the_last_server_restart()) { ... } This will let us do setup checks automatically (i.e., without a specialized setup mode) without imposing hundreds of milliseconds of `git submodule status` and similar checks on every page load, even if an install does not have APC. Broadly, the major goals here are: - Reduce user errors and support costs related to misconfiguration (e.g., failure to update submodules). - Simplify setup and configuration (remove 'phabricator.setup', remove/reduce PHABRICATOR_ENV). - Move as much configuration to the web as possible (required for SaaS). Test Plan: Added this block to webroot/index.php: $cache = PhabricatorCaches::getSetupCache(); $result = $cache->getKeys(array('x')); if (empty($result['x'])) { phlog('Cache miss + set.'); $cache->setKeys(array('x' => 'y')); } else { phlog('Cache hit.'); } Verified it used APC correctly. Disabled APC and verified it degraded to a reasonable disk-based behavior. If we miss both of these we end up with no actual caching, but that's the best we can do. This code will also run too early in setup for it to be appropriate to raise exceptions out of this pathway -- later on, we can raise a warning that APC is not installed. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2227, T2062 Differential Revision: https://secure.phabricator.com/D4281
2012-12-25 15:09:51 +01:00
'PhabricatorCaches' => 'applications/cache/PhabricatorCaches.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Rename PhabricatorUserStatus to PhabricatorCalendarEvent Summary: Ref T4375. We never join this table, so this is a pretty straight find/replace. Test Plan: Browsed around Calendar, verified that nothing seemed broken. Saw my red dot in other apps. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8145
2014-02-06 19:07:29 +01:00
'PhabricatorCalendarEvent' => 'applications/calendar/storage/PhabricatorCalendarEvent.php',
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventDeleteController' => 'applications/calendar/controller/PhabricatorCalendarEventDeleteController.php',
'PhabricatorCalendarEventEditController' => 'applications/calendar/controller/PhabricatorCalendarEventEditController.php',
Rename PhabricatorUserStatus to PhabricatorCalendarEvent Summary: Ref T4375. We never join this table, so this is a pretty straight find/replace. Test Plan: Browsed around Calendar, verified that nothing seemed broken. Saw my red dot in other apps. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8145
2014-02-06 19:07:29 +01:00
'PhabricatorCalendarEventInvalidEpochException' => 'applications/calendar/exception/PhabricatorCalendarEventInvalidEpochException.php',
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventListController' => 'applications/calendar/controller/PhabricatorCalendarEventListController.php',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
'PhabricatorCalendarEventQuery' => 'applications/calendar/query/PhabricatorCalendarEventQuery.php',
Use ApplicationSearch in the calendar event list view Summary: Ref T4375. Basic ApplicationSearch integration to power this more flexibly. Test Plan: {F108762} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8148
2014-02-06 19:10:18 +01:00
'PhabricatorCalendarEventSearchEngine' => 'applications/calendar/query/PhabricatorCalendarEventSearchEngine.php',
Give Calendar events a more modern view/detail page Summary: Ref T4375. Very basic, but gives us a more standard place to put edit/delete operations. Test Plan: {F108765} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8149
2014-02-06 19:10:27 +01:00
'PhabricatorCalendarEventViewController' => 'applications/calendar/controller/PhabricatorCalendarEventViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCalendarHoliday' => 'applications/calendar/storage/PhabricatorCalendarHoliday.php',
'PhabricatorCalendarHolidayTestCase' => 'applications/calendar/storage/__tests__/PhabricatorCalendarHolidayTestCase.php',
Assign PHIDs to calendar events Summary: Ref T4375. We're going to need these for a bunch of infrastructure to work. Test Plan: Ran migrations, checked DB, used `phid.query`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8151
2014-02-06 19:10:43 +01:00
'PhabricatorCalendarPHIDTypeEvent' => 'applications/calendar/phid/PhabricatorCalendarPHIDTypeEvent.php',
Make "My Events" default on Calendar Summary: Moves Browse to "View All" and makes "My Events" the default on Calendar. Test Plan: Browse both pages. Reviewers: btrahan, epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8397
2014-03-05 17:24:45 +01:00
'PhabricatorCalendarViewController' => 'applications/calendar/controller/PhabricatorCalendarViewController.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',
Add unit tests for Git change parsers Summary: Ref T4327. Adds some basic tests to the Git parser for a set of common operations (add, change, move, copy, directory, symlink, propchange). Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8012
2014-01-20 22:14:04 +01:00
'PhabricatorChangeParserTestCase' => 'applications/repository/worker/__tests__/PhabricatorChangeParserTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChangesetResponse' => 'infrastructure/diff/PhabricatorChangesetResponse.php',
Added a new storage object Summary: Added a new storage object. Created PhabricatorChagLogChannel Test Plan: Will be specified by Evan :P Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D4943
2013-02-14 13:10:42 +01:00
'PhabricatorChatLogChannel' => 'applications/chatlog/storage/PhabricatorChatLogChannel.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/PhabricatorChatLogChannelListController.php',
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/PhabricatorChatLogChannelLogController.php',
Modernize chatlog a bit Summary: Ref T4786. This doesn't fully fix the issue since there's no way to make channels public yet, but gets some of the infrastructure more up to date. - Allow public access to the list and log controllers. - Implement proper policy checks in the Events (this has no practical impact on the only controller that loads this stuff, it's just for general/future purposes). - Remove a old-style unused method for building page frames. Test Plan: Viewed log list and log details as logged-in and logged out users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4786 Differential Revision: https://secure.phabricator.com/D8746
2014-04-10 20:45:21 +02:00
'PhabricatorChatLogChannelQuery' => 'applications/chatlog/query/PhabricatorChatLogChannelQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
Modernize chatlog a bit Summary: Ref T4786. This doesn't fully fix the issue since there's no way to make channels public yet, but gets some of the infrastructure more up to date. - Allow public access to the list and log controllers. - Implement proper policy checks in the Events (this has no practical impact on the only controller that loads this stuff, it's just for general/future purposes). - Remove a old-style unused method for building page frames. Test Plan: Viewed log list and log details as logged-in and logged out users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4786 Differential Revision: https://secure.phabricator.com/D8746
2014-04-10 20:45:21 +02:00
'PhabricatorChatLogQuery' => 'applications/chatlog/query/PhabricatorChatLogQuery.php',
Add CustomField to Diffusion and add a "branches" field Summary: Ref T4588. Request from @zeeg. Adds a "BRANCHES" field to commit emails, so the branches the commit appears on are shown. I've implemented this with CustomField, but in a very light way. Test Plan: Used `scripts/repository/reparse.php --herald` to generate mail, got a BRANCHES section where applicable. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley, zeeg Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8501
2014-03-12 19:30:33 +01:00
'PhabricatorCommitBranchesField' => 'applications/repository/customfield/PhabricatorCommitBranchesField.php',
'PhabricatorCommitCustomField' => 'applications/repository/customfield/PhabricatorCommitCustomField.php',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
'PhabricatorCommitSearchEngine' => 'applications/audit/query/PhabricatorCommitSearchEngine.php',
Add a "tags" field to Diffusion commit Summary: - Fixes T4588. - See D8501. - Adds a "Tags" field for Herald commit emails. - Fixes a bug in `tagsquery` when filtering by commit name. - Make `tagsquery` just return nothing instead of fataling against Mercurial/Subversion. Test Plan: Used `bin/repository/reparse.php --herald` to exercise this code. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8502
2014-03-12 19:30:52 +01:00
'PhabricatorCommitTagsField' => 'applications/repository/customfield/PhabricatorCommitTagsField.php',
Add a common password blacklist Summary: Fixes T4143. This mitigates the "use a botnet to slowly try to login to every user account using the passwords '1234', 'password', 'asdfasdf', ..." attack, like the one that hit GitHub. (I also donated some money to Openwall as a thanks for compiling this wordlist.) Test Plan: - Tried to register with a weak password; registered with a strong password. - Tried to set VCS password to a weak password; set VCS password to a strong password. - Tried to change password to a weak password; changed password to a strong password. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T4143 Differential Revision: https://secure.phabricator.com/D8048
2014-01-23 23:01:18 +01:00
'PhabricatorCommonPasswords' => 'applications/auth/constants/PhabricatorCommonPasswords.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitAPIController' => 'applications/conduit/controller/PhabricatorConduitAPIController.php',
'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',
Mostly modernize Conduit logs Summary: - Add GC support to conduit logs. - Add Query support to conduit logs. - Record the actual user PHID. - Show client name. - Support querying by specific method, so I can link to this from a setup issue. @wez, this migration may not be fast. It took about 8 seconds for me to migrate 800,000 rows in the `conduit_methodcalllog` table. This adds a GC which should keep the table at a more manageable size in the future. You can safely delete all data older than 30 days from this table, although you should do it by `id` instead of `dateCreated` since there's no key on `dateCreated` until this patch. Test Plan: - Ran GC. - Looked at log UI. - Ran Conduit methods. Reviewers: btrahan Reviewed By: btrahan CC: wez, aran Differential Revision: https://secure.phabricator.com/D6332
2013-07-01 21:37:34 +02:00
'PhabricatorConduitLogQuery' => 'applications/conduit/query/PhabricatorConduitLogQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/PhabricatorConduitMethodCallLog.php',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitMethodQuery' => 'applications/conduit/query/PhabricatorConduitMethodQuery.php',
'PhabricatorConduitSearchEngine' => 'applications/conduit/query/PhabricatorConduitSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorConduitTokenController' => 'applications/conduit/controller/PhabricatorConduitTokenController.php',
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',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigEntryQuery' => 'applications/config/query/PhabricatorConfigEntryQuery.php',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'infrastructure/env/PhabricatorConfigFileSource.php',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'applications/config/controller/PhabricatorConfigGroupController.php',
Button to ignore setup issues + refractoring Summary: T2381 Test Plan: Click on the ignore link in /config/issue/ and respond to the dialog box. Also, test uninstalling and reinstalling an application in the web UI (to verify that refractoring didn't break anything). Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2381 Differential Revision: https://secure.phabricator.com/D5234
2013-03-06 23:14:09 +01:00
'PhabricatorConfigIgnoreController' => 'applications/config/controller/PhabricatorConfigIgnoreController.php',
Detect and raise setup warnings from within Phabricator Summary: This is basicaly a light version of D4286. The major problem with D4286 is that it's a huge leap and completely replaces the setup process in one step. Instead, I want to do this: - Add the post-setup warnings (yellow bar with "6 unresolved warnings..."). - Copy all setup checks into post-setup warnings (so every check has an old-style check and a new-style check). - Run that for a little bit and make sure it's stable. - Implement fatal post-setup checks (the red screen, vs the yellow bar). - Run that for a little bit. - Nuke setup mode and delete all the old checks. This should give us a bunch of very gradual steps toward the brave new world of simpler setup. Test Plan: - Faked APC setup failures, saw warnings raise. - Verified that this runs after restart (get + set). - Verified that this costs us only one cache hit after first-run (get only). Reviewers: btrahan, codeblock, vrana, chad Reviewed By: codeblock CC: aran Maniphest Tasks: T2228 Differential Revision: https://secure.phabricator.com/D4295
2012-12-30 15:37:49 +01:00
'PhabricatorConfigIssueListController' => 'applications/config/controller/PhabricatorConfigIssueListController.php',
'PhabricatorConfigIssueViewController' => 'applications/config/controller/PhabricatorConfigIssueViewController.php',
Fix error in `PhabricatorSetupIssueView` Summary: - Move `prettyPrintJSON()` and make it static. - Use it from `PhabricatorSetupIssueView` - Update other `config/` places that use it to call it from the new class. This fixes a bug in `PhabricatorSetupIssueView` which showed up if the value was an array and couldn't be rendered by `phutil_escape_html()`. Test Plan: - Rendered some config options. - Went to /config/issue/config.unknown.phame.skins/ without error. Reviewers: epriestley, btrahan, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4411
2013-01-12 00:28:33 +01:00
'PhabricatorConfigJSON' => 'applications/config/json/PhabricatorConfigJSON.php',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'PhabricatorConfigJSONOptionType' => 'applications/config/custom/PhabricatorConfigJSONOptionType.php',
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',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigPHIDTypeConfig' => 'applications/config/phid/PhabricatorConfigPHIDTypeConfig.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 Conpherence Threads to new phid stuff Summary: Ref T2715. Test Plan: loaded conpherence, loaded a different thread, made a conpherence. also phid.query Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6577
2013-07-26 21:07:47 +02:00
'PhabricatorConpherencePHIDTypeThread' => 'applications/conpherence/phid/PhabricatorConpherencePHIDTypeThread.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Consolidate use of magical cookie name strings Summary: Ref T4339. We have more magical cookie names than we should, move them all to a central location. Test Plan: Registered, logged in, linked account, logged out. See inlines. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4339 Differential Revision: https://secure.phabricator.com/D8041
2014-01-23 23:01:35 +01:00
'PhabricatorCookies' => 'applications/auth/constants/PhabricatorCookies.php',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'applications/config/option/PhabricatorCoreConfigOptions.php',
Countdown revamp Summary: countdown_timer table named to countdown. datepoint and related stuff renamed to epoch. Countdowns now have phids. Various UI items changed from timer to countdown. Test Plan: Did run storage upgrade and added some countdowns. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2624 Differential Revision: https://secure.phabricator.com/D5812
2013-05-04 00:49:29 +02:00
'PhabricatorCountdown' => 'applications/countdown/storage/PhabricatorCountdown.php',
Add application and object level policy controls to Countdown Summary: Ref T603. Give countdowns proper UI-level policy controls, and an application-level default policy. Put policy information in the header. Test Plan: - Adjusted default policy. - Created new countdowns. - Edited countdowns. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7322
2013-10-16 19:36:08 +02:00
'PhabricatorCountdownCapabilityDefaultView' => 'applications/countdown/capability/PhabricatorCountdownCapabilityDefaultView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Use application PHIDs in countdown Summary: Ref T2715. Swap countdown to application PHIDs. Test Plan: Used `phid.lookup`; `phid.query`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6532
2013-07-22 23:42:25 +02:00
'PhabricatorCountdownPHIDTypeCountdown' => 'applications/countdown/phid/PhabricatorCountdownPHIDTypeCountdown.php',
'PhabricatorCountdownQuery' => 'applications/countdown/query/PhabricatorCountdownQuery.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PhabricatorCountdownRemarkupRule' => 'applications/countdown/remarkup/PhabricatorCountdownRemarkupRule.php',
Modernize Countdown somewhat Summary: Far from perfect, but better? Test Plan: {F51153} {F51154} {F51155} Reviewers: btrahan, chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6533
2013-07-23 15:16:19 +02:00
'PhabricatorCountdownSearchEngine' => 'applications/countdown/query/PhabricatorCountdownSearchEngine.php',
'PhabricatorCountdownView' => 'applications/countdown/view/PhabricatorCountdownView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorCountdownViewController' => 'applications/countdown/controller/PhabricatorCountdownViewController.php',
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',
Further simplify PhabricatorCustomFieldInterface Summary: Ref T1703. Ref T3718. This introduces `PhabricatorCustomFieldAttachment`, which is just a fancy `array()`. The goal here is to simplify `PhabricatorCustomFieldInterface` as much as possible. In particular, it can now use common infrastructure (`assertAttached()`) and is more difficult to get wrong. Test Plan: Edited custom fields on profile. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1703, T3718 Differential Revision: https://secure.phabricator.com/D6752
2013-08-14 18:53:59 +02:00
'PhabricatorCustomFieldAttachment' => 'infrastructure/customfield/field/PhabricatorCustomFieldAttachment.php',
Allow configuration to have custom UI types Summary: Ref T1703. This sets the stage for (but does not yet implement) custom UI types for config. In particular, a draggable list for custom fields. I might make all the builtin types go through this at some point too, but don't really want to bother for the moment. It would be very slightly cleaner but woudn't get us much of anything. Test Plan: UI now renders via custom code, although that code does nothing (produces an unadorned text field): {F45693} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6154
2013-06-07 21:36:18 +02:00
'PhabricatorCustomFieldConfigOptionType' => 'infrastructure/customfield/config/PhabricatorCustomFieldConfigOptionType.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldDataNotAvailableException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldDataNotAvailableException.php',
'PhabricatorCustomFieldImplementationIncompleteException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldImplementationIncompleteException.php',
'PhabricatorCustomFieldIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldIndexStorage.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldInterface' => 'infrastructure/customfield/interface/PhabricatorCustomFieldInterface.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldList' => 'infrastructure/customfield/field/PhabricatorCustomFieldList.php',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'PhabricatorCustomFieldMonogramParser' => 'infrastructure/customfield/parser/PhabricatorCustomFieldMonogramParser.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldNotAttachedException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldNotAttachedException.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldNotProxyException' => 'infrastructure/customfield/exception/PhabricatorCustomFieldNotProxyException.php',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldNumericIndexStorage.php',
'PhabricatorCustomFieldStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStorage.php',
'PhabricatorCustomFieldStringIndexStorage' => 'infrastructure/customfield/storage/PhabricatorCustomFieldStringIndexStorage.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorDaemonController' => 'applications/daemon/controller/PhabricatorDaemonController.php',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonDAO' => 'applications/daemon/storage/PhabricatorDaemonDAO.php',
Use events rather than Conduit to report daemon status in Phabricator Summary: Ref T1670. Use events and direct database writes instead of Conduit. Deprecate the Conduit methods. Test Plan: Ran daemons, used the console to review daemon event logs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6536
2013-07-23 21:10:02 +02:00
'PhabricatorDaemonEventListener' => 'applications/daemon/event/PhabricatorDaemonEventListener.php',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonLog' => 'applications/daemon/storage/PhabricatorDaemonLog.php',
'PhabricatorDaemonLogEvent' => 'applications/daemon/storage/PhabricatorDaemonLogEvent.php',
Allow long daemon log messages to be expanded Summary: Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569. Provide a link you can click to see the full message. This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them. Test Plan: {F51261} {F51262} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6546
2013-07-23 21:30:58 +02:00
'PhabricatorDaemonLogEventViewController' => 'applications/daemon/controller/PhabricatorDaemonLogEventViewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/PhabricatorDaemonLogEventsView.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonLogGarbageCollector' => 'applications/daemon/garbagecollector/PhabricatorDaemonLogGarbageCollector.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/PhabricatorDaemonLogListController.php',
'PhabricatorDaemonLogListView' => 'applications/daemon/view/PhabricatorDaemonLogListView.php',
Mostly modernize daemon detail views Summary: Ref T3557. The major goals here are: - Modernize use of UI elements. - Present daemon status with more clarity. Particularly, the "Waiting" status is called out and explained in detail. Test Plan: {F51247} {F51248} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6541
2013-07-23 21:10:41 +02:00
'PhabricatorDaemonLogQuery' => 'applications/daemon/query/PhabricatorDaemonLogQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/PhabricatorDaemonLogViewController.php',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementDebugWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementDebugWorkflow.php',
'PhabricatorDaemonManagementLaunchWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementLaunchWorkflow.php',
'PhabricatorDaemonManagementListWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementListWorkflow.php',
Add `bin/phd log <id>` to dump all logs to the CLI Summary: Ref T3557. Make it easier to access full daemon logs from the CLI. Test Plan: {F51265} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6547
2013-07-23 21:48:45 +02:00
'PhabricatorDaemonManagementLogWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementLogWorkflow.php',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementRestartWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementRestartWorkflow.php',
'PhabricatorDaemonManagementStartWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStartWorkflow.php',
'PhabricatorDaemonManagementStatusWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStatusWorkflow.php',
'PhabricatorDaemonManagementStopWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementStopWorkflow.php',
'PhabricatorDaemonManagementWorkflow' => 'applications/daemon/management/PhabricatorDaemonManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/PhabricatorDaemonReference.php',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonTaskGarbageCollector' => 'applications/daemon/garbagecollector/PhabricatorDaemonTaskGarbageCollector.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboard' => 'applications/dashboard/storage/PhabricatorDashboard.php',
Allow panels to appear on dashboards Summary: Ref T3583. Adds edges, query relationships, etc. Lots of debugging/temporary UI. My general intent here is to use edges to track where panels appear, and then put additional data on the dashboard itself to control layout, positioning, etc. Dashboards don't actually render yet so this is still pretty boring. Test Plan: {F149175} {F149176} {F149177} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8916
2014-04-30 23:28:55 +02:00
'PhabricatorDashboardAddPanelController' => 'applications/dashboard/controller/PhabricatorDashboardAddPanelController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardController' => 'applications/dashboard/controller/PhabricatorDashboardController.php',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorDashboardCopyController' => 'applications/dashboard/controller/PhabricatorDashboardCopyController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardDAO' => 'applications/dashboard/storage/PhabricatorDashboardDAO.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardEditController' => 'applications/dashboard/controller/PhabricatorDashboardEditController.php',
Move Dashboard and Panel edit history out of the way Summary: Fixes T5170, Create new page for dashboard history Test Plan: Open dashboard, manage dashboard, click on "View History". Dashboard history should appear. Panel history should appear on panel view page under panel. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5170 Differential Revision: https://secure.phabricator.com/D9280
2014-05-24 21:29:27 +02:00
'PhabricatorDashboardHistoryController' => 'applications/dashboard/controller/PhabricatorDashboardHistoryController.php',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardInstall' => 'applications/dashboard/storage/PhabricatorDashboardInstall.php',
'PhabricatorDashboardInstallController' => 'applications/dashboard/controller/PhabricatorDashboardInstallController.php',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardLayoutConfig' => 'applications/dashboard/layoutconfig/PhabricatorDashboardLayoutConfig.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardListController' => 'applications/dashboard/controller/PhabricatorDashboardListController.php',
Make the default view of dashboards be just the dashboard Summary: Fixes T4985, add manage page, change view page to show only panels. Arguably, PhabricatorDashboardArrangeController is no longer necessary. Also, still trying to figure out if I updated all flows that involve "arrange/{id}". Probably missed some. Also not sure of the Manage Dashboard icon. Please advise. Test Plan: Create dashboard, add panels, "view/{id}" should show just panels, Manage Dashboard should show timeline and edit links. Reviewers: #blessed_reviewers, epriestley, chad Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4985 Differential Revision: https://secure.phabricator.com/D9258
2014-05-22 19:59:46 +02:00
'PhabricatorDashboardManageController' => 'applications/dashboard/controller/PhabricatorDashboardManageController.php',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardMovePanelController' => 'applications/dashboard/controller/PhabricatorDashboardMovePanelController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPHIDTypeDashboard' => 'applications/dashboard/phid/PhabricatorDashboardPHIDTypeDashboard.php',
'PhabricatorDashboardPHIDTypePanel' => 'applications/dashboard/phid/PhabricatorDashboardPHIDTypePanel.php',
'PhabricatorDashboardPanel' => 'applications/dashboard/storage/PhabricatorDashboardPanel.php',
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
'PhabricatorDashboardPanelCoreCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelCoreCustomField.php',
'PhabricatorDashboardPanelCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelCustomField.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelEditController' => 'applications/dashboard/controller/PhabricatorDashboardPanelEditController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelListController' => 'applications/dashboard/controller/PhabricatorDashboardPanelListController.php',
'PhabricatorDashboardPanelQuery' => 'applications/dashboard/query/PhabricatorDashboardPanelQuery.php',
Let dashboard panels render in a very basic way Summary: Ref T3583. This implements very primitive panel rendering on the panel detail page, and an ajaxable standalone view. Test Plan: {F149135} {F149136} {F149137} {F149138} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8913
2014-04-30 23:28:37 +02:00
'PhabricatorDashboardPanelRenderController' => 'applications/dashboard/controller/PhabricatorDashboardPanelRenderController.php',
'PhabricatorDashboardPanelRenderingEngine' => 'applications/dashboard/engine/PhabricatorDashboardPanelRenderingEngine.php',
Allow users to select QueryPanel search engines from a list Summary: Ref T4986. Instead of requiring users to know the name of an application search engine class, let them select from a list. Test Plan: Created a new panel. {F165468} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9500
2014-06-12 22:22:20 +02:00
'PhabricatorDashboardPanelSearchApplicationCustomField' => 'applications/dashboard/customfield/PhabricatorDashboardPanelSearchApplicationCustomField.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelSearchEngine' => 'applications/dashboard/query/PhabricatorDashboardPanelSearchEngine.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelTransaction' => 'applications/dashboard/storage/PhabricatorDashboardPanelTransaction.php',
'PhabricatorDashboardPanelTransactionEditor' => 'applications/dashboard/editor/PhabricatorDashboardPanelTransactionEditor.php',
'PhabricatorDashboardPanelTransactionQuery' => 'applications/dashboard/query/PhabricatorDashboardPanelTransactionQuery.php',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelType' => 'applications/dashboard/paneltype/PhabricatorDashboardPanelType.php',
Rough skeleton of a "Query" dashboard panel Summary: Ref T4986. This isn't pretty/usable yet (I need to move rendering out of ListController classes and into SearchEngine classes, I think) but does pull the correct results. Test Plan: {F151537} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9007
2014-05-07 23:56:30 +02:00
'PhabricatorDashboardPanelTypeQuery' => 'applications/dashboard/paneltype/PhabricatorDashboardPanelTypeQuery.php',
Add a "tabs" dashboard panel type Summary: Ref T4986. Allows you to create a dashboard panel out of dashboard panels. bwahaha Test Plan: {F155472} {F155473} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9141
2014-05-16 04:23:13 +02:00
'PhabricatorDashboardPanelTypeTabs' => 'applications/dashboard/paneltype/PhabricatorDashboardPanelTypeTabs.php',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelTypeText' => 'applications/dashboard/paneltype/PhabricatorDashboardPanelTypeText.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelViewController' => 'applications/dashboard/controller/PhabricatorDashboardPanelViewController.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardQuery' => 'applications/dashboard/query/PhabricatorDashboardQuery.php',
Embed dashboard panels in comments Summary: Fixes T4983, Panel prefix 'W' should be recognized as a shortcut to a dashboard panel Test Plan: Open any comment input, type '{W1}', or other existing panel, preview should embed that panel. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T4983 Differential Revision: https://secure.phabricator.com/D9215
2014-05-20 19:53:27 +02:00
'PhabricatorDashboardRemarkupRule' => 'applications/dashboard/remarkup/PhabricatorDashboardRemarkupRule.php',
Dashboards - add remove functionality Summary: To get there, upgrade "headerless" to "headerMode". Add a new removepanel controller. Fixes T5084. Test Plan: removed some panels to much success Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5078, T5084 Differential Revision: https://secure.phabricator.com/D9156
2014-05-19 23:04:26 +02:00
'PhabricatorDashboardRemovePanelController' => 'applications/dashboard/controller/PhabricatorDashboardRemovePanelController.php',
Give dashboards basic rendering and Ajax support Summary: Ref T3583. Let dashboards "render", sorta. Test Plan: {F149187} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8917
2014-04-30 23:29:14 +02:00
'PhabricatorDashboardRenderingEngine' => 'applications/dashboard/engine/PhabricatorDashboardRenderingEngine.php',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardSearchEngine' => 'applications/dashboard/query/PhabricatorDashboardSearchEngine.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardTransaction' => 'applications/dashboard/storage/PhabricatorDashboardTransaction.php',
'PhabricatorDashboardTransactionEditor' => 'applications/dashboard/editor/PhabricatorDashboardTransactionEditor.php',
'PhabricatorDashboardTransactionQuery' => 'applications/dashboard/query/PhabricatorDashboardTransactionQuery.php',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardUninstallController' => 'applications/dashboard/controller/PhabricatorDashboardUninstallController.php',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardViewController' => 'applications/dashboard/controller/PhabricatorDashboardViewController.php',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'PhabricatorDataNotAttachedException' => 'infrastructure/storage/lisk/PhabricatorDataNotAttachedException.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorDebugController' => 'applications/system/controller/PhabricatorDebugController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorDestructableInterface' => 'applications/system/interface/PhabricatorDestructableInterface.php',
'PhabricatorDestructionEngine' => 'applications/system/engine/PhabricatorDestructionEngine.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
'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',
Modernize email verification page Summary: Fixes T3517. Moves the email verification page out of People and into Auth. Makes it look less awful. Test Plan: {F49636} {F49637} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3517 Differential Revision: https://secure.phabricator.com/D6425
2013-07-11 03:53:09 +02:00
'PhabricatorEmailVerificationController' => 'applications/auth/controller/PhabricatorEmailVerificationController.php',
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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorEnglishTranslation' => 'infrastructure/internationalization/translation/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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorEventListener' => 'infrastructure/events/PhabricatorEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorEventType' => 'infrastructure/events/constant/PhabricatorEventType.php',
Add an example event listener, improve documentation, and add a commit discovery event Summary: Improve documentation around Phabricator events. Test Plan: Generated and read documentation. Ran test script. Reviewers: btrahan, jungejason Reviewed By: jungejason CC: aran Maniphest Tasks: T1092 Differential Revision: https://secure.phabricator.com/D2917
2012-07-04 01:46:27 +02:00
'PhabricatorExampleEventListener' => 'infrastructure/events/PhabricatorExampleEventListener.php',
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',
Clean up image loading for ExternalAccounts Summary: Ref T1536. This gets the single queries out of the View and builds a propery Query class for ExternalAccount. Test Plan: Linked/unlinked accounts, logged out, logged in. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6212
2013-06-17 21:14:00 +02:00
'PhabricatorExternalAccountQuery' => 'applications/auth/query/PhabricatorExternalAccountQuery.php',
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',
Add a feed detail/permalink page for feed stories Summary: Ref T2852. Asana has one bug which I'm having a little trouble figuring out. I want to get more information to debug it, but I'll need them to run `bin/feed republish <story_id>` to get that data. Right now, it's incredibly hard to figure out the story ID for feed stories. So mostly this is to make that easier (click permalink; pull it out of the URL), but it also adds a little functionality and cleans the code up a bit. The page itself could be prettier and maybe some day we'll add comments or whatever, but it seems reasonably functionalish. Test Plan: {F49962} - Also loaded many pages of feed history to check that nothing broke. Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6440
2013-07-13 02:04:02 +02:00
'PhabricatorFeedDetailController' => 'applications/feed/controller/PhabricatorFeedDetailController.php',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedListController' => 'applications/feed/controller/PhabricatorFeedListController.php',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'PhabricatorFeedManagementRepublishWorkflow' => 'applications/feed/management/PhabricatorFeedManagementRepublishWorkflow.php',
'PhabricatorFeedManagementWorkflow' => 'applications/feed/management/PhabricatorFeedManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedQuery' => 'applications/feed/query/PhabricatorFeedQuery.php',
'PhabricatorFeedSearchEngine' => 'applications/feed/query/PhabricatorFeedSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFeedStory' => 'applications/feed/story/PhabricatorFeedStory.php',
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',
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',
'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',
Viewerize ArcBundle file loading callbacks Summary: Ref T603. Clean these up and move them to a single place. Test Plan: - Downloaded a raw diff. - Enabled "attach diffs", created a revision, got an email with a diff. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7179
2013-09-30 21:21:33 +02:00
'PhabricatorFileBundleLoader' => 'applications/files/query/PhabricatorFileBundleLoader.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileCommentController' => 'applications/files/controller/PhabricatorFileCommentController.php',
Add an icon+background selector for project images Summary: Makes it easy to choose distinctive icons for projects. Test Plan: {F71018} {F71020} {F71019} {F71021} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7333
2013-10-17 18:32:34 +02:00
'PhabricatorFileComposeController' => 'applications/files/controller/PhabricatorFileComposeController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorFileController' => 'applications/files/controller/PhabricatorFileController.php',
'PhabricatorFileDAO' => 'applications/files/storage/PhabricatorFileDAO.php',
'PhabricatorFileDataController' => 'applications/files/controller/PhabricatorFileDataController.php',
'PhabricatorFileDeleteController' => 'applications/files/controller/PhabricatorFileDeleteController.php',
'PhabricatorFileDropUploadController' => 'applications/files/controller/PhabricatorFileDropUploadController.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileEditor' => 'applications/files/editor/PhabricatorFileEditor.php',
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',
Use Application PHIDs in Files Summary: Ref T2715. Move files to the new stuff. Test Plan: Used `phid.query`; `phid.lookup` to find files. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6523
2013-07-22 17:02:56 +02:00
'PhabricatorFilePHIDTypeFile' => 'applications/files/phid/PhabricatorFilePHIDTypeFile.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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorFileTemporaryGarbageCollector' => 'applications/files/garbagecollector/PhabricatorFileTemporaryGarbageCollector.php',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'applications/files/storage/__tests__/PhabricatorFileTestCase.php',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'applications/files/lipsum/PhabricatorFileTestDataGenerator.php',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileTransaction' => 'applications/files/storage/PhabricatorFileTransaction.php',
'PhabricatorFileTransactionComment' => 'applications/files/storage/PhabricatorFileTransactionComment.php',
'PhabricatorFileTransactionQuery' => 'applications/files/query/PhabricatorFileTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
'PhabricatorFlagQuery' => 'applications/flag/query/PhabricatorFlagQuery.php',
Implement ApplicationSearch in Flags Summary: Ref T1809. Provide ApplicationSearch to Flags and allow the user to select flags by color. @chad might have some design feedback on my control. Test Plan: {F54131} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D6747
2013-08-14 01:27:26 +02:00
'PhabricatorFlagSearchEngine' => 'applications/flag/query/PhabricatorFlagSearchEngine.php',
'PhabricatorFlagSelectControl' => 'applications/flag/view/PhabricatorFlagSelectControl.php',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
'PhabricatorFlaggableInterface' => 'applications/flag/interface/PhabricatorFlaggableInterface.php',
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',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'PhabricatorGarbageCollector' => 'infrastructure/daemon/garbagecollector/PhabricatorGarbageCollector.php',
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',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/garbagecollector/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',
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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Proide application-based handle loads; load Slowvote handles from the application Summary: Ref T2715. This is pretty straightforward, I think. Notes: - Long term, I want to replace `PhabricatorObjectHandleData` with `PhabricatorObjectQuery` and `PhabricatorHandleQuery`. The former's name is a relic of old Facebook stuff and unusual now that everything else uses normal queries. - I simplified the amount of work applications need to do in order to populate handles. The should just need to set names and URIs in most cases. Test Plan: Used `phid.lookup` and `phid.query` to load slowvote handles. Browsed around to load other handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6508
2013-07-21 16:03:10 +02:00
'PhabricatorHandleQuery' => 'applications/phid/query/PhabricatorHandleQuery.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'PhabricatorHarbormasterConfigOptions' => 'applications/harbormaster/config/PhabricatorHarbormasterConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHash' => 'infrastructure/util/PhabricatorHash.php',
Add PhabricatorHash::digestForIndex() Summary: Does this seem reasonable? It's a bit more compact than digest() (6 bits / byte instead of 4 bits / byte) and 72 bits of entropy @ 12 bytes instead of 128 bits of entropy @ 32 bytes. I feel like it's important to preserve the printability, though, and this seemed like a fairly good balance of concerns. Test Plan: unit tests Reviewers: vrana Reviewed By: vrana CC: aran, yemao932 Differential Revision: https://secure.phabricator.com/D4253
2012-12-21 14:43:33 +01:00
'PhabricatorHashTestCase' => 'infrastructure/util/__tests__/PhabricatorHashTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorHelpEditorProtocolController' => 'applications/help/controller/PhabricatorHelpEditorProtocolController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/PhabricatorHelpKeyboardShortcutController.php',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorHomeController' => 'applications/home/controller/PhabricatorHomeController.php',
'PhabricatorHomeMainController' => 'applications/home/controller/PhabricatorHomeMainController.php',
Add very basic "quick create" menu Summary: Ref T3623. This is like a pre-v0, in that it doesn't have a dropdown yet. Clicking the button takes you to a page which can serve as a right click / mobile / edit target in the long run, but is obviously not great for desktop use. I'll add the dropdown in the next iteration. Test Plan: {F105631} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3623 Differential Revision: https://secure.phabricator.com/D8088
2014-01-29 05:18:01 +01:00
'PhabricatorHomeQuickCreateController' => 'applications/home/controller/PhabricatorHomeQuickCreateController.php',
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',
Add a `bin/hunks` script to manage migrations of hunk data Summary: Ref T4045. Ref T5179. While we'll eventually need to force a migration, we can let installs (particularly large installs) do an online migration for now. This moves hunks to the new storage format one at a time. (Note that nothing writes to the new store yet, so this is the only way to populate it.) WARNING: Installs, don't run this yet! It won't compress the data. Wait until it can also do compression. Test Plan: Added a `break;` after migrating one row and moved a few rows over. Spot checked them in the database and viewed the affected diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9291
2014-05-25 18:54:12 +02:00
'PhabricatorHunksManagementMigrateWorkflow' => 'applications/differential/management/PhabricatorHunksManagementMigrateWorkflow.php',
'PhabricatorHunksManagementWorkflow' => 'applications/differential/management/PhabricatorHunksManagementWorkflow.php',
First pass at decoupling Phabricator bot behavior from the protocol it's running on, this pulls the connection, reading, and writing functionalities out of the bot itself and into the adapter. Summary: Ugh, just wrote out a huge message, only to lose it with a fat-fingered ctrl-c. Le sigh. First pass at decoupling the bot from the protocol. Noticeably absent is the command/message coupling. After this design pass I'll give that a go. Could use some advice, thinking that handlers should only create messages (which can be public or private) and not open ended, undefined 'commands'. The problem being that there needs to be some consistant api if we want handlers to be protocol agnostic. Perhaps that's a pipedream, what are your thoughts? Secondly, a few notes, design review requests on the changes i did make: # Config. For now i'm passing config through to the adapter. This was mainly to remain backwards compatible on the config. I was thinking it should probably be namespaced into it's own subobject though to distinguish the adapter config from the bot config. # Adapter selection. This flavor is the one-bot-daemon, config specified protocol version. The upside is that in the future they won't have to run different daemons for this stuff, just have different config, and the door is open for multiple protocol adapters down the road if need be. The downside is that I had to rename the daemon (non-backwards compatible change) and there will need to be some sort of runtime evaluation for instatiation of the adapter. For now I just have a crude switch, but I was thinking of just taking the string they supply as the class name (ala `try { new $clasName(); } catch...`) so as to allow for homegrown adapters, but I wasn't sure how such runtime magic would go over. Also, an alternative would be to make the PhabricatorBot class a non-abstract non-final base class and have the adapters be accompanied by a bot class that just defines their adapter as a property. The upside of which is backwards compatibility (welcome back PhabricatorIRCBot) and perhaps a little bit clearer plugin path for homegrowners. # Logging. You'll notice I commented out two very important logging lines in the irc adapter. This isn't intended to remain commented out, but I'm not sure what the best way is to get logging at this layer. I'm wary of just composing the daemon back down into the adapter (bi-directional object composition makes my skin crawl), but something needs to happen, obviously. Advice? That's it. After the feedback on the above, you can either merge down, or wait until i finish the command/message refactor if you don't think the diff will grow too large. Up to you, this all functions as is. Test Plan: Ran an irc bot, connected, read input, and wrote output including handler integration. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2462 Differential Revision: https://secure.phabricator.com/D4757
2013-02-06 03:45:20 +01:00
'PhabricatorIRCProtocolAdapter' => 'infrastructure/daemon/bot/adapter/PhabricatorIRCProtocolAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorInternationalizationManagementExtractWorkflow' => 'infrastructure/internationalization/management/PhabricatorInternationalizationManagementExtractWorkflow.php',
'PhabricatorInternationalizationManagementWorkflow' => 'infrastructure/internationalization/management/PhabricatorInternationalizationManagementWorkflow.php',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorIteratedMD5PasswordHasher' => 'infrastructure/util/password/PhabricatorIteratedMD5PasswordHasher.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorJavelinLinter' => 'infrastructure/lint/linter/PhabricatorJavelinLinter.php',
'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',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'PhabricatorLegalpadConfigOptions' => 'applications/legalpad/config/PhabricatorLegalpadConfigOptions.php',
Move LegalpadDocument to new phid stuff Summary: ref T2715 - apologies btw as I didn't catch the "start from the bottom" ask until recently... :/ Test Plan: phid.query for some legalpad documents... booya. also loaded legalpad. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6576
2013-07-26 21:05:33 +02:00
'PhabricatorLegalpadPHIDTypeDocument' => 'applications/legalpad/phid/PhabricatorLegalpadPHIDTypeDocument.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',
'PhabricatorLogoutController' => 'applications/auth/controller/PhabricatorLogoutController.php',
Allow macros to have associated audio and audio behaviors Summary: Ref T3887. Implements storage and editors, but not the actual audio part. Test Plan: Edited audio, audio behaviors of macros. Transactions and email looked good. Hit error cases. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3887 Differential Revision: https://secure.phabricator.com/D7159
2013-09-28 01:01:37 +02:00
'PhabricatorMacroAudioController' => 'applications/macro/controller/PhabricatorMacroAudioController.php',
Modernize policies in Paste and Macro Summary: Ref T603. Fixes T2823. This updates Paste and Macro. - **Paste** - Added default view policy. - I didn't add a "create" policy, since I can't come up with any realistic scenario where you'd give users access to pastes but not let them create them. - **Macro** - Added a "manage" policy, which covers creating and editing macros. This lets an install only allow "People With An Approved Sense of Humor" or whatever to create macros. - Removed the "edit" policy, since giving individual users access to specific macros doesn't make much sense to me. - Changed the view policy to the "most public" policy the install allows. - Added view policy information to the header. Also fix a couple of minor things in Maniphest. Test Plan: - Set Paste policy, created pastes via web and Conduit, saw they got the right default policies. - Set Macro policy, tried to create/edit macros with valid and unauthorized users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2823, T603 Differential Revision: https://secure.phabricator.com/D7317
2013-10-16 19:35:52 +02:00
'PhabricatorMacroCapabilityManage' => 'applications/macro/capability/PhabricatorMacroCapabilityManage.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',
Use application PHIDs in Macro Summary: Ref T2715. Move Macro to application PHIDs. Test Plan: Used `conduit.query` to look up macros. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6556
2013-07-24 23:06:10 +02:00
'PhabricatorMacroPHIDTypeMacro' => 'applications/macro/phid/PhabricatorMacroPHIDTypeMacro.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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailImplementationMailgunAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationMailgunAdapter.php',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerAdapter.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationPHPMailerLiteAdapter.php',
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationSendGridAdapter.php',
'PhabricatorMailImplementationTestAdapter' => 'applications/metamta/adapter/PhabricatorMailImplementationTestAdapter.php',
Move the inbound mail list to the CLI Summary: Same as D6419. See D6413. Test Plan: 13 epriestley D6 Re: [local/Differential] [Request, 83 lines] D6: aabd 14 epriestley D6 Re: [local/Differential] [Request, 83 lines] D6: aabd 15 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 16 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 17 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 18 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 19 - - Re: [local/Diffusion] [Commit] rGTEST8fc313c77729: derp 20 - - (No subject.) 21 epriestley D22 (No subject.) 22 epriestley D12 (No subject.) Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6420
2013-07-11 00:18:37 +02:00
'PhabricatorMailManagementListInboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementListInboundWorkflow.php',
Move outbound mail lists to CLI and enhance details Summary: Finish off moving all this stuff to the CLI. Ref T3306. Test Plan: PROPERTIES ID: 6483 Status: void Retry Count: 0 Next Retry: 1373494457 Related PHID: PHID-DREV-5bnb33yeuhuaulyc3exg Message: Message has no valid recipients: all To/Cc are disabled, invalid, or configured not to receive this mail. PARAMETERS from: PHID-USER-lqiz3yd7wmk64ejugvov is-html: parent-message-id: null thread-id: differential-rev-PHID-DREV-5bnb33yeuhuaulyc3exg-req is-first-message: null is-bulk: 1 mailtags: ["differential-comment"] cc: ["PHID-USER-cluwcdowc35gmperlkbi"] subject: D22: quack quack subject-prefix: [Differential] vary-subject-prefix: [Commented On] worker-task: 936546 HEADERS Thread-Topic: D22: quack quack X-Herald-Rules: none X-Differential-Author: <PHID-USER-lqiz3yd7wmk64ejugvov> X-Differential-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Differential-CC: <PHID-USER-cluwcdowc35gmperlkbi> X-Differential-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Differential-CC: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Differential-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Differential-CC: <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-Explicit-CC: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Differential-Explicit-CC: <PHID-USER-cluwcdowc35gmperlkbi> X-Differential-Explicit-CC: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Differential-Explicit-CC: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Differential-Explicit-CC: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Differential-Explicit-CC: <PHID-USER-cknqtm2dzw7twnwyiaye> X-Differential-Explicit-CCs: <PHID-USER-ly3pvrtdkw7lbgs72jvr>, <PHID-USER-cluwcdowc35gmperlkbi>, <PHID-MLST-wkxaantg3q6pgdkty5pt>, <PHID-USER-aeabc4ipqbifny3rw4ok>, <PHID-USER-zqxtb3oi4pouwxnxlv3f>, <PHID-USER-cknqtm2dzw7twnwyiaye> X-Phabricator-To: <PHID-USER-lqiz3yd7wmk64ejugvov> X-Phabricator-Cc: <PHID-USER-ly3pvrtdkw7lbgs72jvr> X-Phabricator-Cc: <PHID-USER-cluwcdowc35gmperlkbi> X-Phabricator-Cc: <PHID-MLST-wkxaantg3q6pgdkty5pt> X-Phabricator-Cc: <PHID-USER-aeabc4ipqbifny3rw4ok> X-Phabricator-Cc: <PHID-USER-zqxtb3oi4pouwxnxlv3f> X-Phabricator-Cc: <PHID-USER-cknqtm2dzw7twnwyiaye> RECIPIENTS ! dog (dog) - This user is disabled; disabled users do not receive mail. BODY epriestley has commented on the revision "quack quack". zxcbzxcb REVISION DETAIL http://local.aphront.com:8080/D22 To: epriestley Cc: Unknown User, dog, list, duck, epriestley992, asana Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6423
2013-07-11 03:52:22 +02:00
'PhabricatorMailManagementListOutboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementListOutboundWorkflow.php',
Move mail "Receive Test" from web UI to CLI Summary: Ref T3306. Moves this from the web to the CLI, which is a tiny bit clunkier but way better as far as policies go and more repeatable for development. See discussion in D6413. Test Plan: Ran `bin/mail receive-test`, verified mail was received. Used and abused various options. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6417
2013-07-11 00:13:24 +02:00
'PhabricatorMailManagementReceiveTestWorkflow' => 'applications/metamta/management/PhabricatorMailManagementReceiveTestWorkflow.php',
Introduce basic `bin/mail` with a `resend` workflow Summary: Fixes T2458. Ref T2843. @tido's email from T2843 has exhausted its retries and failed, but we want to try it again with the patch from D5464 to capture the actual error. This sort of thing has come up a few times in debugging, too. Also fixed some stuff that came up while debugging this. Test Plan: - Ran command with no args. - Ran resend with no args. - Ran resend with bad IDs. - Ran resend with already-queued messages, got "already queued" error. - Ran resend with already-sent message, got requeue. Reviewers: btrahan, tido Reviewed By: tido CC: aran Maniphest Tasks: T2458, T2843 Differential Revision: https://secure.phabricator.com/D5493
2013-03-30 23:53:49 +01:00
'PhabricatorMailManagementResendWorkflow' => 'applications/metamta/management/PhabricatorMailManagementResendWorkflow.php',
Move "send test" to bin/mail Summary: Like D6417. See D6413. Test Plan: >>> orbital ~/devtools/phabricator $ echo "hello" | ./bin/mail send-test --to dog --cc duck --from epriestley --subject 'hey there' --attach README --tag blip --tag bloop Reading message body from stdin... Mail sent! You can view details by running this command: phabricator/ $ ./bin/mail show-outbound --id 6480 >>> orbital ~/devtools/phabricator $ ./bin/mail show-outbound --id 6480 PROPERTIES ID: 6480 Status: sent Retry Count: 0 Next Retry: 1373493443 Related PHID: Message: PARAMETERS to: ["PHID-USER-cluwcdowc35gmperlkbi"] cc: ["PHID-USER-aeabc4ipqbifny3rw4ok"] subject: hey there is-html: is-bulk: mailtags: ["blip","bloop"] from: PHID-USER-lqiz3yd7wmk64ejugvov worker-task: 936543 BODY hello Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6419
2013-07-11 00:18:24 +02:00
'PhabricatorMailManagementSendTestWorkflow' => 'applications/metamta/management/PhabricatorMailManagementSendTestWorkflow.php',
Provide some diagnostic tools for examining inbound and outbound mail Summary: We can't show this stuff on the web UI because it has password reset links and private reply-to addresses, but we can provide easier CLI tools than "root around in the database". Land a rough version of `bin/mail show-inbound` and `bin/mail show-outbound`. Test Plan: Used both commands to examine mail from the CLI. Reviewers: btrahan Reviewed By: btrahan CC: tido, euresti, aran Differential Revision: https://secure.phabricator.com/D5963
2013-05-20 19:13:42 +02:00
'PhabricatorMailManagementShowInboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowInboundWorkflow.php',
'PhabricatorMailManagementShowOutboundWorkflow' => 'applications/metamta/management/PhabricatorMailManagementShowOutboundWorkflow.php',
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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailgunConfigOptions' => 'applications/config/option/PhabricatorMailgunConfigOptions.php',
Use application PHIDs for mailing lists Summary: Ref T2715. Ref T603. Ref T2625. - Implement policies. - Use policy queries. - Use ApplicationSearch. - Use application PHIDs. Test Plan: Browsed things with lists CC'd; edited lists; created a list, used `phid.query` to query handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625, T2715 Differential Revision: https://secure.phabricator.com/D6513
2013-07-21 19:42:07 +02:00
'PhabricatorMailingListPHIDTypeList' => 'applications/mailinglists/phid/PhabricatorMailingListPHIDTypeList.php',
'PhabricatorMailingListQuery' => 'applications/mailinglists/query/PhabricatorMailingListQuery.php',
'PhabricatorMailingListSearchEngine' => 'applications/mailinglists/query/PhabricatorMailingListSearchEngine.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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorManagementWorkflow' => 'infrastructure/management/PhabricatorManagementWorkflow.php',
Port Maniphest options. Test Plan: Viewed the new options. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4401
2013-01-11 19:24:35 +01:00
'PhabricatorManiphestConfigOptions' => 'applications/maniphest/config/PhabricatorManiphestConfigOptions.php',
Fixed Task Generation Summary: Ref T2903 Test Plan: Successfully generated tasks with authors and owners. Reviewers: epriestley, AnhNhan Reviewed By: epriestley CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5704
2013-04-25 03:17:30 +02:00
'PhabricatorManiphestTaskTestDataGenerator' => 'applications/maniphest/lipsum/PhabricatorManiphestTaskTestDataGenerator.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupCache' => 'applications/cache/storage/PhabricatorMarkupCache.php',
Minor, move all remarkup code to src/infrastructure/markup/
2012-07-02 19:44:37 +02:00
'PhabricatorMarkupEngine' => 'infrastructure/markup/PhabricatorMarkupEngine.php',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorMarkupInterface' => 'infrastructure/markup/PhabricatorMarkupInterface.php',
Provide a concrete class for one-off remarkup blocks Summary: I want to use some of these for instructional text in Diffusion. Provide a concrete class to make one-offs cacheable and switch Releeph to use it. Test Plan: {F44175} Reviewers: btrahan, chad, edward Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6032
2013-05-24 21:37:53 +02:00
'PhabricatorMarkupOneOff' => 'infrastructure/markup/PhabricatorMarkupOneOff.php',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PhabricatorMarkupPreviewController' => 'infrastructure/markup/PhabricatorMarkupPreviewController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMercurialGraphStream' => 'applications/repository/daemon/PhabricatorMercurialGraphStream.php',
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
'PhabricatorMetaMTAActor' => 'applications/metamta/query/PhabricatorMetaMTAActor.php',
'PhabricatorMetaMTAActorQuery' => 'applications/metamta/query/PhabricatorMetaMTAActorQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/PhabricatorMetaMTAAttachment.php',
Implement all remaining config options Summary: Resolves T2255. Test Plan: Looked at mail options. Saw no remaining "Setup Issues". Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4477
2013-01-17 00:06:39 +01:00
'PhabricatorMetaMTAConfigOptions' => 'applications/config/option/PhabricatorMetaMTAConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAController' => 'applications/metamta/controller/PhabricatorMetaMTAController.php',
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/PhabricatorMetaMTADAO.php',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/parser/PhabricatorMetaMTAEmailBodyParser.php',
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/parser/__tests__/PhabricatorMetaMTAEmailBodyParserTestCase.php',
When we fail to process mail, tell the user about it Summary: Ref T4371. Ref T4699. Fixes T3994. Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff. However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening. Thus: - When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address. - Rewrite most of the errors to be more detailed and informative. - Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent.."). - Remove the redundant, less sophisticated code which does something similar in Differential. Test Plan: - Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail. - Hit a bunch of different errors. - Saw reasonable error mail get sent to me. - Saw other reasonable error mail get rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3994, T4371, T4699 Differential Revision: https://secure.phabricator.com/D8692
2014-04-04 03:43:18 +02:00
'PhabricatorMetaMTAErrorMailAction' => 'applications/metamta/action/PhabricatorMetaMTAErrorMailAction.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAMail' => 'applications/metamta/storage/PhabricatorMetaMTAMail.php',
Centralize rendering of application mail bodies Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is. Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible. Reviewers: btrahan, vrana Reviewed By: vrana CC: aran Maniphest Tasks: T931 Differential Revision: https://secure.phabricator.com/D2986
2012-07-17 04:01:43 +02:00
'PhabricatorMetaMTAMailBody' => 'applications/metamta/view/PhabricatorMetaMTAMailBody.php',
'PhabricatorMetaMTAMailBodyTestCase' => 'applications/metamta/view/__tests__/PhabricatorMetaMTAMailBodyTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMetaMTAMailgunReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTAMailgunReceiveController.php',
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',
Expand aggregate email recipients prior to multiplexing Summary: Ref T4361. Before we figure out which To/CC are addressable, try to expand To/CC. Specifically, the supported expansion right now is project PHIDs expanding to all their members. Because of the way multiplexing works, we have to do this in two places: explicitly in `multiplexMail()`, and when sending mail that wasn't multiplexed. This is messy; eventually we can get rid of it (after ApplicationTransactions are everywhere). This has some rough edges, but should basically give us what we need to make stuff like projects mailable. Particularly, it deals with most issues in D7436: - I got around the resolution/multiplexing issue by resolving aggregate mailables separately from mailable actors. - We get to keep the Project PHID as a To/CC/Reviewer/Whatever until the last second. - Users won't get two emails for being a CC and also a member of a CC'd project. - We can degrade to the list stuff this way if we want, by having the project aggregate yield a single list PHID. Test Plan: Added a comment to a revision with a project reviewer, got mail to all the project's members. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4361 Differential Revision: https://secure.phabricator.com/D8117
2014-02-01 23:35:55 +01:00
'PhabricatorMetaMTAMemberQuery' => 'applications/metamta/query/PhabricatorMetaMTAMemberQuery.php',
Allow MetaMTA adapters to indicate that a mail is permanently undeliverable Summary: Currently, adapters can only fail mail temporarily. Allow them to indicate a permanent failure by throwing a special exception. Test Plan: Added and ran unit tests. Reviewers: wez, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6847
2013-08-30 17:21:50 +02:00
'PhabricatorMetaMTAPermanentFailureException' => 'applications/metamta/exception/PhabricatorMetaMTAPermanentFailureException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/PhabricatorMetaMTAReceivedMail.php',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'applications/metamta/exception/PhabricatorMetaMTAReceivedMailProcessingException.php',
'PhabricatorMetaMTAReceivedMailTestCase' => 'applications/metamta/storage/__tests__/PhabricatorMetaMTAReceivedMailTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/PhabricatorMetaMTASendGridReceiveController.php',
'PhabricatorMetaMTAWorker' => 'applications/metamta/PhabricatorMetaMTAWorker.php',
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',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationAdHocFeedStory' => 'applications/notification/feed/PhabricatorNotificationAdHocFeedStory.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationBuilder' => 'applications/notification/builder/PhabricatorNotificationBuilder.php',
Add a "Mark All Read" button for notifications Summary: Adds a button to mark everything as read. Test Plan: Clicked button. Reviewers: btrahan, jungejason, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T974 Differential Revision: https://secure.phabricator.com/D2812
2012-06-20 22:51:19 +02:00
'PhabricatorNotificationClearController' => 'applications/notification/controller/PhabricatorNotificationClearController.php',
Version the Aphlict notification server and prompt users to upgrade if they're out of date Summary: Ref T4324. Add some version information to the server status output, and setup checks to test for an unreachable or out-of-date server. Test Plan: - With server down, hit reasonable setup check. - With server up and at a bad version, hit reasonable setup check. - Viewed `/notification/status/`. - The CSS thing fixes this: {F114445} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8251
2014-02-18 00:59:39 +01:00
'PhabricatorNotificationClient' => 'applications/notification/client/PhabricatorNotificationClient.php',
Move notification configuration into PHP Summary: Bring notification settings to PHP. Test Plan: Viewed notification settings in /config/. Reviewers: codeblock, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4337
2013-01-03 18:29:19 +01:00
'PhabricatorNotificationConfigOptions' => 'applications/config/option/PhabricatorNotificationConfigOptions.php',
Move files in notification one level up. Summary: Moved the files in notification one level up to match the rest of code base. And ran arc liberate. Test Plan: Made sure __phutil_library_map__ points to the right files. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: allenjohnashton, aran, Korvin Differential Revision: https://secure.phabricator.com/D2688
2012-06-08 22:00:07 +02:00
'PhabricatorNotificationController' => 'applications/notification/controller/PhabricatorNotificationController.php',
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',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationTestController' => 'applications/notification/controller/PhabricatorNotificationTestController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthClientAuthorization' => 'applications/oauthserver/storage/PhabricatorOAuthClientAuthorization.php',
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/PhabricatorOAuthClientAuthorizationQuery.php',
'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',
'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',
Make OAuth client authorizations a Settings panel Summary: This modernizes and simplifies OAuth client authorizations a bit, moving them to a settings panel similar to the "Sessions" panel. Test Plan: - Viewed authorizations. - Revoked an authorization. - Created a test authorization. {F131196} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8561
2014-03-18 21:28:19 +01:00
'PhabricatorOAuthServerAuthorizationsSettingsPanel' => 'applications/oauthserver/panel/PhabricatorOAuthServerAuthorizationsSettingsPanel.php',
Use modern UI and policies in OAuth client editing Summary: Updates this stuff a bit: - Add a global create permission for OAuth applications. The primary goal is to reduce attack surface area by making it more difficult for an adversary to do anything which requires that they create and configure an OAuth application/client. Normal users shouldn't generally need to create applications, OAuth is complex, and doing things with user accounts is inherently somewhat administrative. - Use normal policies to check create and edit permissions, now that we have infrastructure for it. - Use modern UI kit. Test Plan: - Created a client. - Edited a client. - Tried to create a client as a non-admin. - Tried to edit a client I don't own. {F131511} {F131512} {F131513} {F131514} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8562
2014-03-18 21:30:48 +01:00
'PhabricatorOAuthServerCapabilityCreateClients' => 'applications/oauthserver/capability/PhabricatorOAuthServerCapabilityCreateClients.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/PhabricatorOAuthServerClient.php',
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/PhabricatorOAuthServerClientQuery.php',
Use ApplicationSearch in OAuthServer Summary: Update the infrastructure and UI of the client list. Test Plan: {F131570} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8563
2014-03-18 21:31:04 +01:00
'PhabricatorOAuthServerClientSearchEngine' => 'applications/oauthserver/query/PhabricatorOAuthServerClientSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/PhabricatorOAuthServerController.php',
'PhabricatorOAuthServerDAO' => 'applications/oauthserver/storage/PhabricatorOAuthServerDAO.php',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
'PhabricatorOAuthServerPHIDTypeClient' => 'applications/oauthserver/phid/PhabricatorOAuthServerPHIDTypeClient.php',
'PhabricatorOAuthServerPHIDTypeClientAuthorization' => 'applications/oauthserver/phid/PhabricatorOAuthServerPHIDTypeClientAuthorization.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorOAuthServerScope' => 'applications/oauthserver/PhabricatorOAuthServerScope.php',
'PhabricatorOAuthServerTestCase' => 'applications/oauthserver/__tests__/PhabricatorOAuthServerTestCase.php',
'PhabricatorOAuthServerTestController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTestController.php',
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/PhabricatorOAuthServerTokenController.php',
'PhabricatorObjectHandle' => 'applications/phid/PhabricatorObjectHandle.php',
'PhabricatorObjectHandleConstants' => 'applications/phid/handle/const/PhabricatorObjectHandleConstants.php',
'PhabricatorObjectHandleStatus' => 'applications/phid/handle/const/PhabricatorObjectHandleStatus.php',
Extract textual object list parsing from Differential Summary: Ref T2222. Currently, Differential has a fairly hairy piece of logic to parse object lists, like `Reviewers: alincoln, htaft`. Extract, generalize, and cover this. - Some of the logic can be simplified with modern ObjectQuery stuff. - Make `@username` the formal monogram for users. - Make `list@domain.com` the formal monogram for mailing lists. - Add test coverage. Test Plan: - Ran unit tests. - Called `differential.parsecommitmessage` with a bunch of real-world inputs and got sensible results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8445
2014-03-08 02:44:44 +01:00
'PhabricatorObjectListQuery' => 'applications/phid/query/PhabricatorObjectListQuery.php',
'PhabricatorObjectListQueryTestCase' => 'applications/phid/query/__tests__/PhabricatorObjectListQueryTestCase.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'applications/metamta/receiver/PhabricatorObjectMailReceiver.php',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'applications/metamta/receiver/__tests__/PhabricatorObjectMailReceiverTestCase.php',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorObjectQuery' => 'applications/phid/query/PhabricatorObjectQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move OwnersPackage to Appliation PHIDs Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6572
2013-07-26 19:31:26 +02:00
'PhabricatorOwnersPHIDTypePackage' => 'applications/owners/phid/PhabricatorOwnersPHIDTypePackage.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
'PhabricatorPHIDConstants' => 'applications/phid/PhabricatorPHIDConstants.php',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorPHIDInterface' => 'applications/phid/interface/PhabricatorPHIDInterface.php',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorPHIDType' => 'applications/phid/type/PhabricatorPHIDType.php',
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',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorPasswordHasher' => 'infrastructure/util/password/PhabricatorPasswordHasher.php',
'PhabricatorPasswordHasherTestCase' => 'infrastructure/util/password/__tests__/PhabricatorPasswordHasherTestCase.php',
'PhabricatorPasswordHasherUnavailableException' => 'infrastructure/util/password/PhabricatorPasswordHasherUnavailableException.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteCommentController' => 'applications/paste/controller/PhabricatorPasteCommentController.php',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PhabricatorPasteConfigOptions' => 'applications/paste/config/PhabricatorPasteConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteController' => 'applications/paste/controller/PhabricatorPasteController.php',
'PhabricatorPasteDAO' => 'applications/paste/storage/PhabricatorPasteDAO.php',
Split paste create/edit and list views Summary: We have this hybrid "create / last few pastes" landing screen right now but I ~never use the list at the bottom and it makes the controller kind of complicated. I want to let you edit pastes too, and this generally simplifies things. Also makes the textarea monospaced and cleans up the fork logic a bit. Test Plan: Created, forked pastes. Viewed paste lists. Viewed pastes. Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1690 Differential Revision: https://secure.phabricator.com/D3375
2012-08-24 22:19:14 +02:00
'PhabricatorPasteEditController' => 'applications/paste/controller/PhabricatorPasteEditController.php',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteEditor' => 'applications/paste/editor/PhabricatorPasteEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Use application PHIDs in Paste Summary: Ref T2715. Switch Paste to application PHIDs. Test Plan: Used `conduit.query`; `conduit.lookup`; grepped for constants. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6555
2013-07-24 20:32:49 +02:00
'PhabricatorPastePHIDTypePaste' => 'applications/paste/phid/PhabricatorPastePHIDTypePaste.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteQuery' => 'applications/paste/query/PhabricatorPasteQuery.php',
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',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteTransaction' => 'applications/paste/storage/PhabricatorPasteTransaction.php',
'PhabricatorPasteTransactionComment' => 'applications/paste/storage/PhabricatorPasteTransactionComment.php',
'PhabricatorPasteTransactionQuery' => 'applications/paste/query/PhabricatorPasteTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPasteViewController' => 'applications/paste/controller/PhabricatorPasteViewController.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleApproveController' => 'applications/people/controller/PhabricatorPeopleApproveController.php',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PhabricatorPeopleCalendarController' => 'applications/people/controller/PhabricatorPeopleCalendarController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleController' => 'applications/people/controller/PhabricatorPeopleController.php',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleCreateController' => 'applications/people/controller/PhabricatorPeopleCreateController.php',
Move "Delete User" action to user profiles Summary: Ref T4065. The existence of two separate edit workflows for users is broadly confusing to administrators. I want to unify user administration and improve administration of system agent accounts. Particularly, I plan to: - Give administrators limited access to profile editing of system agents (e.g., change profile picture). - Give administrators limited access to Settings for system agents. - Broadly, move all the weird old special editing into standard editing. Test Plan: - Hit all the errors (delete self, no username, wrong username). - Deleted a user. - Visited page as a non-admin, got 403'd. - Viewed old edit UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8662
2014-04-02 21:05:07 +02:00
'PhabricatorPeopleDeleteController' => 'applications/people/controller/PhabricatorPeopleDeleteController.php',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleDisableController' => 'applications/people/controller/PhabricatorPeopleDisableController.php',
Put Disable/Admin flags on profiles Summary: Ref T4065. Moves the "disable / enable" and "make / unmake administrator" actions to profiles. Test Plan: Disabled and enabled users, and made and unmade administrators. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8666
2014-04-02 21:05:49 +02:00
'PhabricatorPeopleEmpowerController' => 'applications/people/controller/PhabricatorPeopleEmpowerController.php',
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',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
'PhabricatorPeopleLogQuery' => 'applications/people/query/PhabricatorPeopleLogQuery.php',
'PhabricatorPeopleLogSearchEngine' => 'applications/people/query/PhabricatorPeopleLogSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleLogsController' => 'applications/people/controller/PhabricatorPeopleLogsController.php',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleNewController' => 'applications/people/controller/PhabricatorPeopleNewController.php',
Use Application PHIDs for XUSR Summary: Ref T2715. XUSR -> apps Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6558
2013-07-24 23:12:39 +02:00
'PhabricatorPeoplePHIDTypeExternal' => 'applications/people/phid/PhabricatorPeoplePHIDTypeExternal.php',
Move PhabricatorUser to new phid stuff Summary: Ref T2715. Had to start loading status information in the query class. Debated trying to clean up some of the attach / load stuff but decided to just add status under the new paradigm for now. Test Plan: phid.query also made a status and checked that out. also played in conpherence. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6585
2013-07-26 23:05:19 +02:00
'PhabricatorPeoplePHIDTypeUser' => 'applications/people/phid/PhabricatorPeoplePHIDTypeUser.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPeopleProfileController' => 'applications/people/controller/PhabricatorPeopleProfileController.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorPeopleProfileEditController' => 'applications/people/controller/PhabricatorPeopleProfileEditController.php',
Improve UI for selecting profile pictures Summary: Ref T1703. Move profile pictures to a separate, dedicated interface. Instead of the 35 controls we currently provide, just show all the possible images we can find and then let the user upload an additional one if they want. Possible improvements to this interface: - Write an edge so we can show old profile pictures too. - The cropping/scaling got a bit buggy at some point, fix that. - Refresh OAuth sources which we're capable of refreshing before showing images (more work than I really want to deal with). - We could show little inset icons for the image source ("f" for Facebook, etc.) instead of just the tooltips. Test Plan: Chose images, uploaded new images, hit various error cases. {F49344} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2919, T1703 Differential Revision: https://secure.phabricator.com/D6398
2013-07-10 01:23:54 +02:00
'PhabricatorPeopleProfilePictureController' => 'applications/people/controller/PhabricatorPeopleProfilePictureController.php',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleQuery' => 'applications/people/query/PhabricatorPeopleQuery.php',
Move "Change Username" from weird edit panel to standard object action Summary: Ref T4065. Make this work in a more standard way which administrators have a reasonable shot at finding and using. See D8662 for discussion. Test Plan: Changed a user's username. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8663
2014-04-02 21:05:19 +02:00
'PhabricatorPeopleRenameController' => 'applications/people/controller/PhabricatorPeopleRenameController.php',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleSearchEngine' => 'applications/people/query/PhabricatorPeopleSearchEngine.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'applications/people/lipsum/PhabricatorPeopleTestDataGenerator.php',
Move "Send Welcome Email" to profiles and nuke old weird edit UI Summary: Ref T4065. Moves the last of the weird alternate edit UI to profiles. The old "Edit" controller is now for creation only, and the funky pencil icon is gone. Test Plan: Created accounts; sent welcome email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8670
2014-04-02 21:06:17 +02:00
'PhabricatorPeopleWelcomeController' => 'applications/people/controller/PhabricatorPeopleWelcomeController.php',
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',
Move PhameBlog to new phid stuff Summary: Ref T2715 Test Plan: loaded phame and viewed all blogs link. did phid.query successfully Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6578
2013-07-26 21:19:12 +02:00
'PhabricatorPhamePHIDTypeBlog' => 'applications/phame/phid/PhabricatorPhamePHIDTypeBlog.php',
Move PhamePost to new phid stuff Summary: Ref T2715 Test Plan: phid.query and a brief phame post read Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6579
2013-07-26 22:15:08 +02:00
'PhabricatorPhamePHIDTypePost' => 'applications/phame/phid/PhabricatorPhamePHIDTypePost.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',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicies' => 'applications/policy/constants/PhabricatorPolicies.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicy' => 'applications/policy/storage/PhabricatorPolicy.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyAwareQuery' => 'infrastructure/query/policy/PhabricatorPolicyAwareQuery.php',
'PhabricatorPolicyAwareTestQuery' => 'applications/policy/__tests__/PhabricatorPolicyAwareTestQuery.php',
Allow applications to define new policy capabilities Summary: Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI. Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability. That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate. Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier. Also provide more context, and more useful exception messages. Test Plan: - See screenshots. - Also triggered a policy exception and verified it was dramatically more useful than it used to be. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
'PhabricatorPolicyCapability' => 'applications/policy/capability/PhabricatorPolicyCapability.php',
'PhabricatorPolicyCapabilityCanEdit' => 'applications/policy/capability/PhabricatorPolicyCapabilityCanEdit.php',
'PhabricatorPolicyCapabilityCanJoin' => 'applications/policy/capability/PhabricatorPolicyCapabilityCanJoin.php',
'PhabricatorPolicyCapabilityCanView' => 'applications/policy/capability/PhabricatorPolicyCapabilityCanView.php',
Move policy config to "Policy" app and make `policy.allow-public` description scarier Summary: Ref T603. We have a real policy app now, so put the config options there. Revise the description of the public policy switch to make it clear that enabling it immediately opens up the user directory and various other interfaces. Test Plan: Viewed/edited config setting. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7154
2013-09-27 19:50:19 +02:00
'PhabricatorPolicyConfigOptions' => 'applications/policy/config/PhabricatorPolicyConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyConstants' => 'applications/policy/constants/PhabricatorPolicyConstants.php',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyController' => 'applications/policy/controller/PhabricatorPolicyController.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyDAO' => 'applications/policy/storage/PhabricatorPolicyDAO.php',
Make Maniphest list page react to viewer capabilities Summary: Ref T603. Basically: - Hide "Reports". - Hide "batch edit" and "export to excel". - Hide reprioritization controls. - I left the edit controls, they show a "login to continue" dialog when hit. - Allow tokenizer results to fill for public users. - Fix a bug where membership in projects was computed incorrectly in certain cases. - Add a unit test covering the project membership bug. Test Plan: Viewed /maniphest/ when logged out, and while logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7126
2013-09-25 22:45:04 +02:00
'PhabricatorPolicyDataTestCase' => 'applications/policy/__tests__/PhabricatorPolicyDataTestCase.php',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyEditController' => 'applications/policy/controller/PhabricatorPolicyEditController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyException' => 'applications/policy/exception/PhabricatorPolicyException.php',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyExplainController' => 'applications/policy/controller/PhabricatorPolicyExplainController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorPolicyFilter' => 'applications/policy/filter/PhabricatorPolicyFilter.php',
'PhabricatorPolicyInterface' => 'applications/policy/interface/PhabricatorPolicyInterface.php',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementShowWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementShowWorkflow.php',
Add `bin/policy unlock` Summary: Ref T603. We might need a fine-grained CLI tool later on, but here's a bat we can bludgeon things with. Test Plan: - Ran `bin/policy unlock D12` (adjusted policies). - Ran `bin/policy unlock rPca85c457ebcb` (got "not mutable" stuff). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7189
2013-10-02 01:01:15 +02:00
'PhabricatorPolicyManagementUnlockWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementUnlockWorkflow.php',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementWorkflow' => 'applications/policy/management/PhabricatorPolicyManagementWorkflow.php',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyPHIDTypePolicy' => 'applications/policy/phid/PhabricatorPolicyPHIDTypePolicy.php',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPolicyQuery' => 'applications/policy/query/PhabricatorPolicyQuery.php',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyRule' => 'applications/policy/rule/PhabricatorPolicyRule.php',
'PhabricatorPolicyRuleAdministrators' => 'applications/policy/rule/PhabricatorPolicyRuleAdministrators.php',
Legalpad - add policy rule for legalpad document signatures Summary: Ref T3116. This creates a policy rule where you can require a signature on a given legalpad document. NOTE: signatures must be for the *latest* document version. Test Plan: made a task have a custom policy requiring a legalpad signature. verified non-signers were locked out. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7977
2014-01-16 01:48:44 +01:00
'PhabricatorPolicyRuleLegalpadSignature' => 'applications/policy/rule/PhabricatorPolicyRuleLegalpadSignature.php',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyRuleLunarPhase' => 'applications/policy/rule/PhabricatorPolicyRuleLunarPhase.php',
'PhabricatorPolicyRuleProjects' => 'applications/policy/rule/PhabricatorPolicyRuleProjects.php',
'PhabricatorPolicyRuleUsers' => 'applications/policy/rule/PhabricatorPolicyRuleUsers.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
'PhabricatorProject' => 'applications/project/storage/PhabricatorProject.php',
Move "Archive Project" to a standard, separate action Summary: Ref T4379. Projects currently include their "delete/disable" function as part of edit, which is atypical. Instead, provide it as a first-class action. This is primarily for consistency between applications. (The action list on projects is getting pretty huge, but we can deal with that separately; I have some ideas.) Test Plan: Archived/unarchived a project. Edited a project. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8177
2014-02-10 23:30:47 +01:00
'PhabricatorProjectArchiveController' => 'applications/project/controller/PhabricatorProjectArchiveController.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectBoardController' => 'applications/project/controller/PhabricatorProjectBoardController.php',
Workboards - let users delete columns Summary: Fixes T4408. I had to add a "status" to colum. I think we'll need this once we get fancier anyway but for now we have "active" and deleted. Test Plan: deleted a column. noted reloaded workboard with all those tasks back in the default colun. loaded a task and saw the initial transaction had a "Disabled" icon next to the deleted workboard. also saw the new transaction back to the default column worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4408 Differential Revision: https://secure.phabricator.com/D8544
2014-03-18 18:40:31 +01:00
'PhabricatorProjectBoardDeleteController' => 'applications/project/controller/PhabricatorProjectBoardDeleteController.php',
Adding the create flow for Project Board (Workphlow) columns. Summary: This adds in the create flow for the Project board columns on the super secret board page which totally doesn't do anything right now. Test Plan: 1. Apply diff. 2. Go to super secret page. 3. Click link close to top with a way too long name. 4. Enter a name for the column. 5. Enjoy a new column briefly before realising you cannot remove it. 6. Stay happy! Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: tmaroschik, Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7925
2014-01-10 01:09:38 +01:00
'PhabricatorProjectBoardEditController' => 'applications/project/controller/PhabricatorProjectBoardEditController.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectBoardViewController' => 'applications/project/controller/PhabricatorProjectBoardViewController.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumn' => 'applications/project/storage/PhabricatorProjectColumn.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnDetailController' => 'applications/project/controller/PhabricatorProjectColumnDetailController.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumnQuery' => 'applications/project/query/PhabricatorProjectColumnQuery.php',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnTransaction' => 'applications/project/storage/PhabricatorProjectColumnTransaction.php',
'PhabricatorProjectColumnTransactionEditor' => 'applications/project/editor/PhabricatorProjectColumnTransactionEditor.php',
'PhabricatorProjectColumnTransactionQuery' => 'applications/project/query/PhabricatorProjectColumnTransactionQuery.php',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectConfigOptions' => 'applications/project/config/PhabricatorProjectConfigOptions.php',
'PhabricatorProjectConfiguredCustomField' => 'applications/project/customfield/PhabricatorProjectConfiguredCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectConstants' => 'applications/project/constants/PhabricatorProjectConstants.php',
'PhabricatorProjectController' => 'applications/project/controller/PhabricatorProjectController.php',
'PhabricatorProjectCreateController' => 'applications/project/controller/PhabricatorProjectCreateController.php',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectCustomField' => 'applications/project/customfield/PhabricatorProjectCustomField.php',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectCustomFieldNumericIndex' => 'applications/project/storage/PhabricatorProjectCustomFieldNumericIndex.php',
'PhabricatorProjectCustomFieldStorage' => 'applications/project/storage/PhabricatorProjectCustomFieldStorage.php',
'PhabricatorProjectCustomFieldStringIndex' => 'applications/project/storage/PhabricatorProjectCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectDAO' => 'applications/project/storage/PhabricatorProjectDAO.php',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectDescriptionField' => 'applications/project/customfield/PhabricatorProjectDescriptionField.php',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditDetailsController' => 'applications/project/controller/PhabricatorProjectEditDetailsController.php',
Project - add ability to select an icon for typeaheads and such Summary: Fixes T5090. Introduced getIcon into Handle stack which allows you to specify a per handle icon. getIcon falls back ot getTypeIcon. Test Plan: changed the icon on a project a bunch. verified transactions showed up. verified icon showed up in typeahead. verified icon showed up in tokens that were pre-generated (not typed in). units test passed. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5090 Differential Revision: https://secure.phabricator.com/D9264
2014-05-23 19:41:24 +02:00
'PhabricatorProjectEditIconController' => 'applications/project/controller/PhabricatorProjectEditIconController.php',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditMainController' => 'applications/project/controller/PhabricatorProjectEditMainController.php',
'PhabricatorProjectEditPictureController' => 'applications/project/controller/PhabricatorProjectEditPictureController.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',
Project - add ability to select an icon for typeaheads and such Summary: Fixes T5090. Introduced getIcon into Handle stack which allows you to specify a per handle icon. getIcon falls back ot getTypeIcon. Test Plan: changed the icon on a project a bunch. verified transactions showed up. verified icon showed up in typeahead. verified icon showed up in tokens that were pre-generated (not typed in). units test passed. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5090 Differential Revision: https://secure.phabricator.com/D9264
2014-05-23 19:41:24 +02:00
'PhabricatorProjectIcon' => 'applications/project/icon/PhabricatorProjectIcon.php',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectInterface' => 'applications/project/interface/PhabricatorProjectInterface.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectListController' => 'applications/project/controller/PhabricatorProjectListController.php',
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',
Use standard UI kit on project member page Summary: Fixes T4400. Removes very, very old "PhabricatorObjectListView", which was only used here. Test Plan: {F132249} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T4400 Differential Revision: https://secure.phabricator.com/D8574
2014-03-20 03:30:27 +01:00
'PhabricatorProjectMembersRemoveController' => 'applications/project/controller/PhabricatorProjectMembersRemoveController.php',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PhabricatorProjectMoveController' => 'applications/project/controller/PhabricatorProjectMoveController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectPHIDTypeColumn' => 'applications/project/phid/PhabricatorProjectPHIDTypeColumn.php',
Use Application PHIDs in Projects Summary: Ref T2715. Move Projects to the new stuff. Test Plan: Used `phid.query` to load projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6526
2013-07-22 18:26:26 +02:00
'PhabricatorProjectPHIDTypeProject' => 'applications/project/phid/PhabricatorProjectPHIDTypeProject.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectProfileController' => 'applications/project/controller/PhabricatorProjectProfileController.php',
'PhabricatorProjectQuery' => 'applications/project/query/PhabricatorProjectQuery.php',
Use ApplicationSearch in projects Summary: Ref T2715. I stripped a bunch of stuff from the list since it was buggy, slow, or both. Some day, we'll rebuild it. Test Plan: {F51128} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6525
2013-07-22 17:34:35 +02:00
'PhabricatorProjectSearchEngine' => 'applications/project/query/PhabricatorProjectSearchEngine.php',
Index projects in the main search index Summary: Part one of a large and complicated plot: - The last filter for Maniphest "pro" queries is "Group By". - This is currently executed in a convoluted and ridiculous way, loading massive amounts of data. - The primary reason it works like it does is that we don't have a project name index available in Maniphest, so we can't sort in the DB. - So, I want to provide a name index to Maniphest and push this work to the DB. To do that, my plan is: - Index projects in Search. - Add a "did update index" event. - Have Maniphest listen for it. - When projects are updated, update their indexes in Maniphest. - Rewrite the giant mess of "group by: project" to be somewhat reasonable. - This may also extend to some future "group by: assignee". This is the first small step down this path, which just indexes projects in search. Test Plan: Ran `bin/search index --type project`, then searched for projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6955
2013-09-12 22:05:19 +02:00
'PhabricatorProjectSearchIndexer' => 'applications/project/search/PhabricatorProjectSearchIndexer.php',
Projects - add "Additional Hashtags" to projects Summary: Fixes T4021. Chooses to keep a "primary" slug based off the name - including all that lovely logic - and allow the user to specify "additional" slugs. Expose these as "hashtags" to the user. Sets us up for a fun diff where we can delete all the Project => Phriction automagicalness. In terms of this diff, see the TODOs i added. Test Plan: added a primary slug as an additional slug - got an error. added a slug in use on another project - got an error. added multiple good slugs and they worked. removed slugs and it worked. made some remark using multiple new slugs and they all linked to the correct project ran epriestley's case - Create project "A". - Give it additional slug "B". - Try to create project "B". and i got a nice error about hashtag collision Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4021 Differential Revision: https://secure.phabricator.com/D9250
2014-05-22 20:19:03 +02:00
'PhabricatorProjectSlug' => 'applications/project/storage/PhabricatorProjectSlug.php',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectStandardCustomField' => 'applications/project/customfield/PhabricatorProjectStandardCustomField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectStatus' => 'applications/project/constants/PhabricatorProjectStatus.php',
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'applications/project/lipsum/PhabricatorProjectTestDataGenerator.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectTransaction' => 'applications/project/storage/PhabricatorProjectTransaction.php',
Implement "Edit Members" and "Join/Leave" with real ApplicationTransactions Summary: Ref T4379. Projects has been partially converted to ApplicationTransactions, but the rough state of the world is that all the //storage// is modern, but most of the stuff on top isn't yet. Particularly, there's a `PhabricatorProjectEditor` which is //not// a subclass of `PhabricatorApplicationTransactionEditor`, but which fakes its way through writing reasonable data into modern storage. This introduces a real transaction editor, `PhabricatorProjectTransactionEditor`, with the eventual goal of moving all of the old functionality into it and deleting the old class. This diff only moves the membership transaction into new code (it doesn't even move all of it -- when we create a project, we add the author as a member, and that can't move quite yet since there are other transactions at the same time). Test Plan: - Created a new project. - Edited members. - Joined / left project. - This already has a pile of unit test coverage. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8167
2014-02-10 23:30:00 +01:00
'PhabricatorProjectTransactionEditor' => 'applications/project/editor/PhabricatorProjectTransactionEditor.php',
Add project history and title strings Summary: Ref T4010. Adds a history page and restores the transaction title strings, which previously sort-of existed in the defunct feed story class. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7371
2013-10-22 22:49:37 +02:00
'PhabricatorProjectTransactionQuery' => 'applications/project/query/PhabricatorProjectTransactionQuery.php',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectUIEventListener' => 'applications/project/events/PhabricatorProjectUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorProjectUpdateController' => 'applications/project/controller/PhabricatorProjectUpdateController.php',
Allow projects to be "watched", sort of a super-subscribe Summary: Ref T4967. Adds a "Watch" relationship to projects, which is stronger than member/subscribed. Specifically, when a task is tagged with a project, we'll include all project watchers in the email/notifications. Normally we don't include projects unless they're explicitly CC'd, or have some other active role in the object (like being a reviewer or auditor). This allows you to closely follow a project without needing to write a Herald rule for every project you care about. Test Plan: - Watched/unwatched a project. - Tested the watch/subscribe/member relationships: - Watching implies subscribe. - Joining implies subscribe. - Leaving implies unsubscribe + unwatch. - You can't unsubscribe until you unwatch (slightly better would be unsubscribe implies unwatch, but this is a bit tricky). - Watched a project, then recevied email about a tagged task without otherwise being involved. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4967 Differential Revision: https://secure.phabricator.com/D9185
2014-05-19 21:40:57 +02:00
'PhabricatorProjectWatchController' => 'applications/project/controller/PhabricatorProjectWatchController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Implement Graphviz, Figlet and Cowsay as Remarkup interpreter blocks Summary: Fixes T3274. Fixes T3964. Ref T3591. Test Plan: {F70928} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3274, T3964, T3591 Differential Revision: https://secure.phabricator.com/D7332
2013-10-17 04:12:14 +02:00
'PhabricatorRemarkupBlockInterpreterCowsay' => 'infrastructure/markup/interpreter/PhabricatorRemarkupBlockInterpreterCowsay.php',
'PhabricatorRemarkupBlockInterpreterFiglet' => 'infrastructure/markup/interpreter/PhabricatorRemarkupBlockInterpreterFiglet.php',
'PhabricatorRemarkupBlockInterpreterGraphviz' => 'infrastructure/markup/interpreter/PhabricatorRemarkupBlockInterpreterGraphviz.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',
Make remarkup rules runtime-pluggable in a reasonable way Summary: Gets rid of some old Differential-specific nonsense and replaces it with general runtime-pluggable Remarkup rules. Facebook: This removes two options which may be in use. Have any classes being added via config here just subclass the new abstract bases instead. This should take 5 seconds to fix. You can adjust order by overriding `getPriority()` on the rules, if necessary. Test Plan: See comments. Reviewers: btrahan Reviewed By: btrahan CC: FacebookPOC, andrewjcg, aran Differential Revision: https://secure.phabricator.com/D7393
2013-10-25 02:26:07 +02:00
'PhabricatorRemarkupCustomBlockRule' => 'infrastructure/markup/rule/PhabricatorRemarkupCustomBlockRule.php',
'PhabricatorRemarkupCustomInlineRule' => 'infrastructure/markup/rule/PhabricatorRemarkupCustomInlineRule.php',
Make the "NOTE:" text bold and slightly darker Summary: See screenshot. This does look like an improvement to me. Test Plan: {F133255} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley, chad Differential Revision: https://secure.phabricator.com/D8597
2014-03-23 02:06:46 +01:00
'PhabricatorRemarkupExample' => 'applications/uiexample/examples/PhabricatorRemarkupExample.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',
move repository arcanist projects over to new phid stuff Summary: also submit casual entry for longest class name award with new query class. Ref T2715 Test Plan: phid.query and saw the right arcanist project Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6586
2013-07-26 23:33:31 +02:00
'PhabricatorRepositoryArcanistProjectQuery' => 'applications/repository/query/PhabricatorRepositoryArcanistProjectQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
'PhabricatorRepositoryDAO' => 'applications/repository/storage/PhabricatorRepositoryDAO.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'applications/repository/engine/PhabricatorRepositoryDiscoveryEngine.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'applications/repository/editor/PhabricatorRepositoryEditor.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryEngine' => 'applications/repository/engine/PhabricatorRepositoryEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryGitCommitChangeParserWorker.php',
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryGitCommitMessageParserWorker.php',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryGraphCache' => 'applications/repository/graphcache/PhabricatorRepositoryGraphCache.php',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorRepositoryGraphStream' => 'applications/repository/daemon/PhabricatorRepositoryGraphStream.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryListController' => 'applications/repository/controller/PhabricatorRepositoryListController.php',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryManagementCacheWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementCacheWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementDiscoverWorkflow.php',
Add `bin/repository edit` for CLI repository editing Summary: Ref T4039. This is mostly to deal with that, to prevent the security issues associated with mutable local paths. The next diff will lock them in the web UI. I also added a confirmation prompt to `bin/repository delete`, which was a little scary without one. See one comment inline about the `--as` flag. I don't love this, but when I started adding all the stuff we'd need to let this transaction show up as "Administrator" it quickly got pretty big. Test Plan: Ran `bin/repository edit ...`, saw an edit with a transaction show up on the web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4039 Differential Revision: https://secure.phabricator.com/D7579
2013-11-13 20:26:05 +01:00
'PhabricatorRepositoryManagementEditWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementEditWorkflow.php',
Add an administrative `bin/repository importing` command to list importing commits Summary: Ref T4068. Adds a command to list all commits in an "importing" status. This will allow users to use `reparse.php` to diagnose and repair issues. Test Plan: - Ran `bin/repository importing P`, etc. - Used `reparse.php` to reparse some commit stages and saw status update correctly. - Ran on a repo with no importing commits. - Ran with `... --simple | xargs`, which saves us having to put an `awk` or something in there for users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7515
2013-11-06 20:26:41 +01:00
'PhabricatorRepositoryManagementImportingWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementImportingWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementListWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementListWorkflow.php',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'PhabricatorRepositoryManagementLookupUsersWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementLookupUsersWorkflow.php',
Add an administrative `bin/repository mark-imported` command Summary: Ref T4068. In some cases like that one, I anticipate a repository not fully importing when a handful of random commits are broken. In the long run we should just deal with that properly, but in the meantime provide an administrative escape hatch so you can mark the repository as imported and get it running normally. The major reason to do this is that Herald, Feed, Harbormaster, etc., won't activate until a repository is "imported". Test Plan: - Tried to mark an imported repository as imported, got an "already imported" message. - Same for not-imported. - Marked a repository not-imported. - Marked a repository imported. - Marked a repository not-imported, then waited for the daemons to mark it imported again automatically. Reviewers: btrahan Reviewed By: btrahan CC: aran, kbrownlees Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7514
2013-11-06 20:26:24 +01:00
'PhabricatorRepositoryManagementMarkImportedWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementMarkImportedWorkflow.php',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryManagementMirrorWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementMirrorWorkflow.php',
Record parent relationships when discovering commits Summary: Ref T4455. This adds a `repository_parents` table which stores `<childCommitID, parentCommitID>` relationships. For new commits, it is populated when commits are discovered. For older commits, there's a `bin/repository parents` script to rebuild the data. Right now, there's no UI suggestion that you should run the script. I haven't come up with a super clean way to do this, and this table will only improve performance for now, so it's not important that we get everyone to run the script right away. I'm just leaving it for the moment, and we can figure out how to tell admins to run it later. The ultimate goal is to solve T2683, but solving T4455 gets us some stuff anyway (for example, we can serve `diffusion.commitparentsquery` faster out of this cache). Test Plan: - Used `bin/repository discover` to discover new commits in Git, SVN and Mercurial repositories. - Used `bin/repository parents` to rebuild Git and Mercurial repositories (SVN repos just exit with a message). - Verified that the table appears to be sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley Maniphest Tasks: T4455 Differential Revision: https://secure.phabricator.com/D9044
2014-05-10 21:41:18 +02:00
'PhabricatorRepositoryManagementParentsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementParentsWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementPullWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementPullWorkflow.php',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryManagementRefsWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementRefsWorkflow.php',
Separate repository updates from the pull daemon Summary: Ref T4605. Currently, the PullLocal daemon is responsible for two relatively distinct things: - scheduling repository updates; and - actually updating repositories. Move the "actually updating" part into a new `bin/repository update` command, which basically runs the pull, discover, refs and mirror commands. This will let the parent process focus on scheduling in a more understandable way and update multiple repositories at once. It also makes it easier to debug and understand update behavior since the non-scheduling pipeline can be run separately. Test Plan: - Ran `update --trace` on SVN, Mercurial and Git repos. - Ran PullLocal daemon for a while without issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4605 Differential Revision: https://secure.phabricator.com/D8780
2014-04-16 22:00:29 +02:00
'PhabricatorRepositoryManagementUpdateWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementUpdateWorkflow.php',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementWorkflow' => 'applications/repository/management/PhabricatorRepositoryManagementWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositoryMercurialCommitChangeParserWorker.php',
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositoryMercurialCommitMessageParserWorker.php',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryMirror' => 'applications/repository/storage/PhabricatorRepositoryMirror.php',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryMirrorEngine' => 'applications/repository/engine/PhabricatorRepositoryMirrorEngine.php',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryMirrorQuery' => 'applications/repository/query/PhabricatorRepositoryMirrorQuery.php',
move repository arcanist projects over to new phid stuff Summary: also submit casual entry for longest class name award with new query class. Ref T2715 Test Plan: phid.query and saw the right arcanist project Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6586
2013-07-26 23:33:31 +02:00
'PhabricatorRepositoryPHIDTypeArcanistProject' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypeArcanistProject.php',
Use Application PHIDs for commits Summary: Ref T2716. Ref T2715. Move CMIT to use Application PHIDs. Nothing too special here, but I consolidated some code into DiffusionCommitQuery. Depends on D6514. Test Plan: Browsed Diffusion. Browsed Differential/Maniphest with linked commits. Used jump nav; used `phid.lookup` and `phid.query`. Used remarkup for Git and SVN repos. Grepped for PHID_TYPE_CMIT. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T2716 Differential Revision: https://secure.phabricator.com/D6515
2013-07-21 19:57:07 +02:00
'PhabricatorRepositoryPHIDTypeCommit' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypeCommit.php',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryPHIDTypeMirror' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypeMirror.php',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPHIDTypePushEvent' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypePushEvent.php',
Assign PHIDs to PushLogs Summary: Ref T4195. We need these in Herald, since HeraldTranscripts need to refer to a PHID which they acted upon. Test Plan: Ran migration, got PHIDs: mysql> select phid from repository_pushlog limit 3; +--------------------------------+ | phid | +--------------------------------+ | PHID-PSHL-25jnc6cjgzw5rwqgmr7r | | PHID-PSHL-2vrvmtslkrj5yv7nxsv2 | | PHID-PSHL-34x262zkrwoka6mplony | +--------------------------------+ 3 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7780
2013-12-18 00:23:23 +01:00
'PhabricatorRepositoryPHIDTypePushLog' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypePushLog.php',
Use application PHIDs in Repositories Summary: Ref T2715. Move repositories to new app PHIDs. Test Plan: Used `phid.lookup`; `phid.query`; browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6529
2013-07-22 19:45:12 +02:00
'PhabricatorRepositoryPHIDTypeRepository' => 'applications/repository/phid/PhabricatorRepositoryPHIDTypeRepository.php',
Begin making change parsers testable Summary: Ref T4327. There are a bunch of other probably-related tasks too, some linked there. We have some rare/unusual bugs in the change parsers, mostly in Subversion, but it's terrifying to touch them because they're complicated and fragile and have no test coverage. To fix this stuff, I want to make them more testable. In particular, they basically end with this big INSERT right now. Instead, I'm going to make them return objects representing the data to be inserted, then have the common infrastructure do the insert. This gives us two benefits: - Reduced code duplication on the insert; - we can stop before the insert and have unit tests examine the objects. This swaps the Git parser over, but doesn't swap the hg/svn parsers yet. I'll do those separately, the SVN one looks a bit tricky. Test Plan: - Used `scripts/repository/reparse.php` to reparse a Git commit, with `--trace`. Verified it looked the same as before and the SQL that was executed seemed reasonable. - Did the same for `hg` / `svn` commits, to make sure I didn't derp anything. These aren't expected to do anything differently. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7980
2014-01-20 22:12:44 +01:00
'PhabricatorRepositoryParsedChange' => 'applications/repository/data/PhabricatorRepositoryParsedChange.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorRepositoryPullEngine' => 'applications/repository/engine/PhabricatorRepositoryPullEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/PhabricatorRepositoryPullLocalDaemon.php',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPushEvent' => 'applications/repository/storage/PhabricatorRepositoryPushEvent.php',
'PhabricatorRepositoryPushEventQuery' => 'applications/repository/query/PhabricatorRepositoryPushEventQuery.php',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'PhabricatorRepositoryPushLog' => 'applications/repository/storage/PhabricatorRepositoryPushLog.php',
'PhabricatorRepositoryPushLogQuery' => 'applications/repository/query/PhabricatorRepositoryPushLogQuery.php',
'PhabricatorRepositoryPushLogSearchEngine' => 'applications/repository/query/PhabricatorRepositoryPushLogSearchEngine.php',
Allow users to receive email about pushes via Herald Summary: Fixes T4677. Implements a "send an email" pre-receive action, which sends push summaries. For use cases where features are often pushed as a large number of commits (e.g., checkpoint commits are retained), using commit emails means users get a ton of email. Instead, this allows you to get an email about a push, which summarizes what changed. Overall, this is basically the same as commit email, but more suitable for some workflows. Test Plan: Wrote some rules, then made a bunch of pushes. Got email like this: {F134929} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8618
2014-03-26 18:44:06 +01:00
'PhabricatorRepositoryPushMailWorker' => 'applications/repository/worker/PhabricatorRepositoryPushMailWorker.php',
'PhabricatorRepositoryPushReplyHandler' => 'applications/repository/mail/PhabricatorRepositoryPushReplyHandler.php',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'applications/repository/query/PhabricatorRepositoryQuery.php',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryRefCursor' => 'applications/repository/storage/PhabricatorRepositoryRefCursor.php',
'PhabricatorRepositoryRefCursorQuery' => 'applications/repository/query/PhabricatorRepositoryRefCursorQuery.php',
'PhabricatorRepositoryRefEngine' => 'applications/repository/engine/PhabricatorRepositoryRefEngine.php',
Use ApplicationSearch in Diffusion Summary: Ref T2625. Switches Diffusion to ApplicationSearch. Notes: - Rendering is a bit rough, I'll clean that up next. - Ordering is a bit arbitrary, also coming shortly. Test Plan: Used `/diffusion/` to execute various searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6917
2013-09-11 00:26:08 +02:00
'PhabricatorRepositorySearchEngine' => 'applications/repository/query/PhabricatorRepositorySearchEngine.php',
Add "RepositoryStatusMessage" and detailed information about initilization Summary: `RepositoryStatusMessage` is basically a key/value table associated with a repository that I'm using to let the daemons store the most recent event of a given type, so we can easily show it on the status dashboard. I think this will be a lot easier for users to figure out than digging through logfiles. I'm also going to write the "this needs a pull" status here eventually, for reducing the time lapse between pushes and discovery. - Add storage for these messages. - Have the pull engine populate the INIT phase. I'll do the FETCH phase next. - Update the status readout to show all the various states. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7461
2013-10-31 00:04:19 +01:00
'PhabricatorRepositoryStatusMessage' => 'applications/repository/storage/PhabricatorRepositoryStatusMessage.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php',
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/PhabricatorRepositorySvnCommitMessageParserWorker.php',
'PhabricatorRepositorySymbol' => 'applications/repository/storage/PhabricatorRepositorySymbol.php',
'PhabricatorRepositoryTestCase' => 'applications/repository/storage/__tests__/PhabricatorRepositoryTestCase.php',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'applications/repository/storage/PhabricatorRepositoryTransaction.php',
'PhabricatorRepositoryTransactionQuery' => 'applications/repository/query/PhabricatorRepositoryTransactionQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorRepositoryType' => 'applications/repository/constants/PhabricatorRepositoryType.php',
Move repository URI normalization out of PullLocalDaemon Summary: Ref T4327. Moves us one small step forward toward testable change parsers by separating out this unrelated logic from the PullLocal daemon. We will also probably want to run this logic so we can do remote path lookups to limit the role of Arcanist Projects in the future, which is why I made the URI type (here, only "git") a parameter rather than calling this a `GitURINormalizer` or something. Test Plan: - Ran unit tests. - Ran `repository discover` on a correctly-configured remote repository. - Ran `repository discover` on an incorrectly-configured remote, got an error message. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7981
2014-01-16 19:49:03 +01:00
'PhabricatorRepositoryURINormalizer' => 'applications/repository/data/PhabricatorRepositoryURINormalizer.php',
'PhabricatorRepositoryURINormalizerTestCase' => 'applications/repository/data/__tests__/PhabricatorRepositoryURINormalizerTestCase.php',
Fix some repository URI handling issues in Git and Mercurial Summary: See <https://github.com/facebook/phabricator/issues/467>. @dctrwatson also ran into an issue where we were trying to `setPass()` a GitURI. - For Git and Mercurial, properly generate credential URIs where relevant. - Don't try to `setPass()` on Git-style URIs. This isn't perfect but should clean things up a bit. Test Plan: Added unit tests. Lots of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: dctrwatson, aran Differential Revision: https://secure.phabricator.com/D7759
2013-12-12 18:45:27 +01:00
'PhabricatorRepositoryURITestCase' => 'applications/repository/storage/__tests__/PhabricatorRepositoryURITestCase.php',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'PhabricatorRepositoryVCSPassword' => 'applications/repository/storage/PhabricatorRepositoryVCSPassword.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorRobotsController' => 'applications/system/controller/PhabricatorRobotsController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/PhabricatorS3FileStorageEngine.php',
Add SMS support Summary: Provides a working SMS implementation with support for Twilio. This version doesn't really retry if we get any gruff at all. Future versions should retry. Test Plan: used bin/sms to send messages and look at them. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aurelijus, epriestley, Korvin Maniphest Tasks: T920 Differential Revision: https://secure.phabricator.com/D8930
2014-05-09 21:47:21 +02:00
'PhabricatorSMS' => 'infrastructure/sms/storage/PhabricatorSMS.php',
'PhabricatorSMSConfigOptions' => 'applications/config/option/PhabricatorSMSConfigOptions.php',
'PhabricatorSMSDAO' => 'infrastructure/sms/storage/PhabricatorSMSDAO.php',
'PhabricatorSMSDemultiplexWorker' => 'infrastructure/sms/worker/PhabricatorSMSDemultiplexWorker.php',
'PhabricatorSMSImplementationAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationAdapter.php',
'PhabricatorSMSImplementationTestBlackholeAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationTestBlackholeAdapter.php',
'PhabricatorSMSImplementationTwilioAdapter' => 'infrastructure/sms/adapter/PhabricatorSMSImplementationTwilioAdapter.php',
'PhabricatorSMSManagementListOutboundWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementListOutboundWorkflow.php',
'PhabricatorSMSManagementSendTestWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementSendTestWorkflow.php',
'PhabricatorSMSManagementShowOutboundWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementShowOutboundWorkflow.php',
'PhabricatorSMSManagementWorkflow' => 'infrastructure/sms/management/PhabricatorSMSManagementWorkflow.php',
'PhabricatorSMSSendWorker' => 'infrastructure/sms/worker/PhabricatorSMSSendWorker.php',
'PhabricatorSMSWorker' => 'infrastructure/sms/worker/PhabricatorSMSWorker.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorSQLPatchList' => 'infrastructure/storage/patch/PhabricatorSQLPatchList.php',
Add a "Generate Keypair" option on the SSH Keys panel Summary: Ref T4587. Add an option to automatically generate a keypair, associate the public key, and save the private key. Test Plan: Generated some keypairs. Hit error conditions, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8513
2014-03-13 02:17:11 +01:00
'PhabricatorSSHKeyGenerator' => 'infrastructure/util/PhabricatorSSHKeyGenerator.php',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorSSHLog' => 'infrastructure/log/PhabricatorSSHLog.php',
Generalize SSH passthru for repository hosting Summary: Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN. For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`. The way this will work is: - The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects. - The `willWriteCallback` will look at those messages and determine if they're reads or writes. - If they're writes, it will check for write permission. - If we're good to go, the message object is converted back into a byte stream and handed to the underlying command. Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo). Reviewers: btrahan Reviewed By: btrahan CC: hach-que, asherkin, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
'PhabricatorSSHPassthruCommand' => 'infrastructure/ssh/PhabricatorSSHPassthruCommand.php',
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',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchApplicationSearchEngine' => 'applications/search/query/PhabricatorSearchApplicationSearchEngine.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchAttachController' => 'applications/search/controller/PhabricatorSearchAttachController.php',
'PhabricatorSearchBaseController' => 'applications/search/controller/PhabricatorSearchBaseController.php',
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',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchDocumentQuery' => 'applications/search/query/PhabricatorSearchDocumentQuery.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/PhabricatorSearchDocumentRelationship.php',
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',
'PhabricatorSearchSelectController' => 'applications/search/controller/PhabricatorSearchSelectController.php',
Perform search indexing in the worker queue and respect `bin/search index --background` Summary: Fixes T3857. Earlier work made this trivial and just left product questions, which I've answered by requiring the daemons to run on reasonable installs. Test Plan: Ran `bin/search index` and `bin/search index --background`. Observed indexes write in the former case and tasks queue in the latter case. Commented with a unique string on a revision and searched for it a moment later, got exactly one result (that revision), verifying that reindexing works correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7966
2014-01-14 22:22:56 +01:00
'PhabricatorSearchWorker' => 'applications/search/worker/PhabricatorSearchWorker.php',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'applications/config/option/PhabricatorSecurityConfigOptions.php',
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',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSettingsAddEmailAction' => 'applications/settings/action/PhabricatorSettingsAddEmailAction.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'applications/settings/controller/PhabricatorSettingsAdjustController.php',
'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',
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorSettingsPanelActivity' => 'applications/settings/panel/PhabricatorSettingsPanelActivity.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
'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',
Improve usability of DarkConsole settings Summary: Fixes T3632. Cleans up a bunch of DarkConsole stuff: - The config setting had out-of-date instructions. Modernize the instructions. - The setting was sort of hidden under "Display Preferences". Move it to a new "Developer Preferences". - The setting magically appeared if DarkConsole was enabled on the install. Instead, always show it but explain why it isn't availalbe. - When the user enables the console, also force it to actually be shown. - Call out instructions about use of the "`" key more clearly. Test Plan: Viewed config setting. Viewed settings panel. Changed setting. Enabling the setting showed DarkConsole. Reviewers: garoevans, chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3632 Differential Revision: https://secure.phabricator.com/D6594
2013-07-28 05:18:58 +02:00
'PhabricatorSettingsPanelDeveloperPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelDeveloperPreferences.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',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorSettingsPanelExternalAccounts' => 'applications/settings/panel/PhabricatorSettingsPanelExternalAccounts.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',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorSettingsPanelMultiFactor' => 'applications/settings/panel/PhabricatorSettingsPanelMultiFactor.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
'PhabricatorSettingsPanelPassword' => 'applications/settings/panel/PhabricatorSettingsPanelPassword.php',
'PhabricatorSettingsPanelSSHKeys' => 'applications/settings/panel/PhabricatorSettingsPanelSSHKeys.php',
'PhabricatorSettingsPanelSearchPreferences' => 'applications/settings/panel/PhabricatorSettingsPanelSearchPreferences.php',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorSettingsPanelSessions' => 'applications/settings/panel/PhabricatorSettingsPanelSessions.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',
Version the Aphlict notification server and prompt users to upgrade if they're out of date Summary: Ref T4324. Add some version information to the server status output, and setup checks to test for an unreachable or out-of-date server. Test Plan: - With server down, hit reasonable setup check. - With server up and at a bad version, hit reasonable setup check. - Viewed `/notification/status/`. - The CSS thing fixes this: {F114445} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8251
2014-02-18 00:59:39 +01:00
'PhabricatorSetupCheckAphlict' => 'applications/notification/setup/PhabricatorSetupCheckAphlict.php',
Add first-time-setup registration flow Summary: Ref T1536. Currently, when you install Phabricator you're dumped on the login screen and have to consult the documentation to learn about `bin/accountadmin`. Instead, detect that an install is running first-time setup: - It has no configured providers; and - it has no user accounts. We can safely deduce that such an install isn't configured yet, and let the user create an admin account from the web UI. After they login, we raise a setup issue and lead them to configure authentication. (This could probably use some UI and copy tweaks.) Test Plan: {F46738} {F46739} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6228
2013-06-20 01:28:48 +02:00
'PhabricatorSetupCheckAuth' => 'applications/config/check/PhabricatorSetupCheckAuth.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',
Warn if daemons are not running Summary: Currently, we try to mostly-kind-of-work if daemons aren't running (for example, we send mail in-process). I want to stop doing this. A major motivator is that `metamta.send-immediately` is confusing for a lot of users and frequently the cause of performance problems. Increasingly, functionality of applications depends on the daemons (Harbormaster, Drydock, Nuance all require daemons to do anything at all). They're also fairly stable/robust/well-tested and no reasonable install should be running without them. This will let us simplify or remove some flags (like `metamta.send-immediately`) and simplify some other processes like search indexing. Test Plan: Stopped daemons, loaded warnings, saw daemon warning. Started daemons, reloade, no warning. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7964
2014-01-14 22:22:40 +01:00
'PhabricatorSetupCheckDaemons' => 'applications/config/check/PhabricatorSetupCheckDaemons.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',
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',
Raise a setup warning for missing or invalid local repository directory Summary: I'm planning to add more detailed info to Diffusion itself, but catch the big issue here. Test Plan: Hit config issue locally, then resolved it. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7439
2013-10-30 21:07:09 +01:00
'PhabricatorSetupCheckRepositories' => 'applications/config/check/PhabricatorSetupCheckRepositories.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',
Provide application and object level policy controls in Slowvote Summary: Ref T603. Gives the create/edit interface a policy control, and adds an application-level default. Test Plan: Created and edited polls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7321
2013-10-16 19:36:00 +02:00
'PhabricatorSlowvoteCapabilityDefaultView' => 'applications/slowvote/capability/PhabricatorSlowvoteCapabilityDefaultView.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/PhabricatorSlowvoteChoice.php',
Ability to close poll Summary: Fixes T3566 List of poll actions should include ability to close an open poll or reopen a closed poll. Test Plan: Poll author should be able to close/reopen poll. Non-author should get policy screen when attempting to close/reopen poll. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T3566 Differential Revision: https://secure.phabricator.com/D8846
2014-04-24 21:00:31 +02:00
'PhabricatorSlowvoteCloseController' => 'applications/slowvote/controller/PhabricatorSlowvoteCloseController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteComment' => 'applications/slowvote/storage/PhabricatorSlowvoteComment.php',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteCommentController' => 'applications/slowvote/controller/PhabricatorSlowvoteCommentController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteController.php',
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/PhabricatorSlowvoteDAO.php',
Make most slowvote fields edit transactionally Summary: No support for responses yet, since they're more complicated, but put everything else on the transactions plan. This also prepares polls for editability, shortly. Test Plan: {F50205} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6460
2013-07-15 19:50:38 +02:00
'PhabricatorSlowvoteEditController' => 'applications/slowvote/controller/PhabricatorSlowvoteEditController.php',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteEditor' => 'applications/slowvote/editor/PhabricatorSlowvoteEditor.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/PhabricatorSlowvoteListController.php',
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/PhabricatorSlowvoteOption.php',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorSlowvotePHIDTypePoll' => 'applications/slowvote/phid/PhabricatorSlowvotePHIDTypePoll.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/PhabricatorSlowvotePoll.php',
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/PhabricatorSlowvotePollController.php',
Add PhabricatorSlowvoteQuery Summary: Ref T603. Ref T2625. Start pushing Slowvote (the greatest app of all time) into the modern era. Test Plan: Looked at vote detail. Used `V1` and `{V1}` embeds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6444
2013-07-13 19:41:30 +02:00
'PhabricatorSlowvoteQuery' => 'applications/slowvote/query/PhabricatorSlowvoteQuery.php',
Use ApplicationSearch in Slowvote Summary: Ref T2625. Ref T603. Make the vote list policy-aware, mobile-friendly, and use ApplicationSearch. Test Plan: {F50022} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6445
2013-07-13 19:41:49 +02:00
'PhabricatorSlowvoteSearchEngine' => 'applications/slowvote/query/PhabricatorSlowvoteSearchEngine.php',
Migrate Slowvote comments to ApplicationTransactions Summary: Move comments from the old table to ApplicationTransactions. Patch dances around which objects it uses since I intend to delete the comment table. NOTE: This temporarily disables comment writes. I'll restore them shortly. Test Plan: {F50166} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6454
2013-07-15 13:20:10 +02:00
'PhabricatorSlowvoteTransaction' => 'applications/slowvote/storage/PhabricatorSlowvoteTransaction.php',
'PhabricatorSlowvoteTransactionComment' => 'applications/slowvote/storage/PhabricatorSlowvoteTransactionComment.php',
'PhabricatorSlowvoteTransactionQuery' => 'applications/slowvote/query/PhabricatorSlowvoteTransactionQuery.php',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'applications/slowvote/controller/PhabricatorSlowvoteVoteController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorSlug' => 'infrastructure/util/PhabricatorSlug.php',
'PhabricatorSlugTestCase' => 'infrastructure/util/__tests__/PhabricatorSlugTestCase.php',
'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',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomField' => 'infrastructure/customfield/standard/PhabricatorStandardCustomField.php',
Implement standard field "bool" type Summary: Depends on D7005. Implements the existing "bool" type. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7006
2013-09-17 01:03:51 +02:00
'PhabricatorStandardCustomFieldBool' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldBool.php',
Implement a "credential" standard custom field Summary: Ref T4590. Ref T1049. This is primarily intended to support HTTP auth in Harbormaster. Test Plan: Added a field, edited it, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4590, T1049 Differential Revision: https://secure.phabricator.com/D8607
2014-03-26 00:13:27 +01:00
'PhabricatorStandardCustomFieldCredential' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldCredential.php',
Add a "date" standard custom field Summary: See previous revisions. As maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7009
2013-09-17 01:04:31 +02:00
'PhabricatorStandardCustomFieldDate' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldDate.php',
Add a "Header" standard custom field Summary: Ref T418. This is the last of the Maniphest field types, although I have a few more capabilities/options to port over. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7018
2013-09-17 23:22:04 +02:00
'PhabricatorStandardCustomFieldHeader' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldHeader.php',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldInt' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldInt.php',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorStandardCustomFieldInterface' => 'infrastructure/customfield/interface/PhabricatorStandardCustomFieldInterface.php',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldPHIDs' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldPHIDs.php',
Implement a "remarkup" standard field type Summary: See D7006, etc. This one's easy since exposing it to ApplicationSearch doesn't make much sense. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7008
2013-09-17 01:04:18 +02:00
'PhabricatorStandardCustomFieldRemarkup' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldRemarkup.php',
Implement a "select" standard custom field type Summary: See D7006, etc. Brings this from Maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7007
2013-09-17 01:04:08 +02:00
'PhabricatorStandardCustomFieldSelect' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldSelect.php',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldText' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldText.php',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldUsers' => 'infrastructure/customfield/standard/PhabricatorStandardCustomFieldUsers.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorStandardPageView' => 'view/page/PhabricatorStandardPageView.php',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorStatusController' => 'applications/system/controller/PhabricatorStatusController.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Move "scripts/sql/probe.php" to "bin/storage probe" Summary: This makes it namespace/database/connection aware and a little easier to find. Also use pht() / PhutilConsole. Test Plan: Ran `bin/storage probe`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6341
2013-07-03 01:34:17 +02:00
'PhabricatorStorageManagementProbeWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementProbeWorkflow.php',
Minor, move all storage/query/db code to src/infrastructure/storage
2012-07-02 19:49:00 +02:00
'PhabricatorStorageManagementStatusWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementStatusWorkflow.php',
'PhabricatorStorageManagementUpgradeWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementUpgradeWorkflow.php',
'PhabricatorStorageManagementWorkflow' => 'infrastructure/storage/management/workflow/PhabricatorStorageManagementWorkflow.php',
'PhabricatorStoragePatch' => 'infrastructure/storage/management/PhabricatorStoragePatch.php',
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',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'PhabricatorSubscriptionsListController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsListController.php',
Transactions - add "and X others" dialog support to application transactions Summary: Fixes T4430. Basically does a little code massage from the new stuff in D8525 and application transactions to get this working. Adds a new controller to the subscriptions app to make rendering these pretty easy peasy. Test Plan: Used my test task in D8525 to verify both add and rem versions of these dialogs worked correctly. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, chad, Korvin Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8540
2014-03-14 22:27:45 +01:00
'PhabricatorSubscriptionsTransactionController' => 'applications/subscriptions/controller/PhabricatorSubscriptionsTransactionController.php',
Add basic "Subscriptions" application Summary: Basic infrastructure for generalizing subscriptions/CCs for T1808, T1514 and T1663. - Implement `PhabricatorSubscribableInterface` and you'll get a subscribe/unsubscribe button for free. - If there are any auto-subscribed users (like the question author) you can specify them; this makes more sense for Tasks and Revisions than Ponder probably, but maybe the author should be auto-subscribed. - Subscriptions are either "explicit" (the user clicked 'subscribe') or "implicit" (the user did something which causes them to become subscribed naturally). If a user unsubscribes, they'll no longer be added by implicit subscriptions. This may or may not be relevant to Ponder but is an existing Herald feature in Differential. - Helper method on PhabricatorSubscribersQuery to load subscribers. - This doesn't handle actually sending email, etc. I think that's all so application-specific that it doesn't belong here. - Now seems to work. Test Plan: {F20552} {F20553} Reviewers: pieter, btrahan Reviewed By: pieter CC: aran Maniphest Tasks: T1663, T1514, T1808 Differential Revision: https://secure.phabricator.com/D3637
2012-10-05 22:18:05 +02:00
'PhabricatorSubscriptionsUIEventListener' => 'applications/subscriptions/events/PhabricatorSubscriptionsUIEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemAction' => 'applications/system/action/PhabricatorSystemAction.php',
'PhabricatorSystemActionEngine' => 'applications/system/engine/PhabricatorSystemActionEngine.php',
'PhabricatorSystemActionGarbageCollector' => 'applications/system/garbagecollector/PhabricatorSystemActionGarbageCollector.php',
'PhabricatorSystemActionLog' => 'applications/system/storage/PhabricatorSystemActionLog.php',
'PhabricatorSystemActionRateLimitException' => 'applications/system/exception/PhabricatorSystemActionRateLimitException.php',
'PhabricatorSystemDAO' => 'applications/system/storage/PhabricatorSystemDAO.php',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemDestructionGarbageCollector' => 'applications/system/garbagecollector/PhabricatorSystemDestructionGarbageCollector.php',
'PhabricatorSystemDestructionLog' => 'applications/system/storage/PhabricatorSystemDestructionLog.php',
'PhabricatorSystemRemoveDestroyWorkflow' => 'applications/system/management/PhabricatorSystemRemoveDestroyWorkflow.php',
'PhabricatorSystemRemoveLogWorkflow' => 'applications/system/management/PhabricatorSystemRemoveLogWorkflow.php',
'PhabricatorSystemRemoveWorkflow' => 'applications/system/management/PhabricatorSystemRemoveWorkflow.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorTestController' => 'applications/base/controller/__tests__/PhabricatorTestController.php',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorTestDataGenerator' => 'applications/lipsum/generator/PhabricatorTestDataGenerator.php',
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',
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',
Enrich "gave a token" feed story Summary: Name the token which was given in the feed story. Test Plan: Gave/rescinded tokens. Looked at a feed story. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7110
2013-09-25 02:00:31 +02:00
'PhabricatorTokenPHIDTypeToken' => 'applications/tokens/phid/PhabricatorTokenPHIDTypeToken.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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorTranslation' => 'infrastructure/internationalization/translation/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',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadCompositeDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadCompositeDatasource.php',
'PhabricatorTypeaheadDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadDatasource.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadDatasourceController.php',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadModularDatasourceController' => 'applications/typeahead/controller/PhabricatorTypeaheadModularDatasourceController.php',
'PhabricatorTypeaheadMonogramDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadMonogramDatasource.php',
Make typeahead results more structured Summary: Get rid of this positional array garbage. Test Plan: Used typeaheads in menu, herald, maniphest, differential, repository/projects. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1569 Differential Revision: https://secure.phabricator.com/D3116
2012-08-01 21:36:19 +02:00
'PhabricatorTypeaheadResult' => 'applications/typeahead/storage/PhabricatorTypeaheadResult.php',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadRuntimeCompositeDatasource' => 'applications/typeahead/datasource/PhabricatorTypeaheadRuntimeCompositeDatasource.php',
Add UI for choosing header color Summary: See D7731. Fixes T4194. Test Plan: {F88020} Reviewers: chad, btrahan Reviewed By: chad CC: aran, mbishopim3 Maniphest Tasks: T4194 Differential Revision: https://secure.phabricator.com/D7740
2013-12-07 19:46:09 +01:00
'PhabricatorUIConfigOptions' => 'applications/config/option/PhabricatorUIConfigOptions.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUIExample' => 'applications/uiexample/examples/PhabricatorUIExample.php',
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/PhabricatorUIExampleRenderController.php',
'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',
Add PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PhabricatorUIStatusExample' => 'applications/uiexample/examples/PhabricatorUIStatusExample.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'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',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorUserConfiguredCustomField' => 'applications/people/customfield/PhabricatorUserConfiguredCustomField.php',
'PhabricatorUserConfiguredCustomFieldStorage' => 'applications/people/storage/PhabricatorUserConfiguredCustomFieldStorage.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserCustomField' => 'applications/people/customfield/PhabricatorUserCustomField.php',
Integrate ApplicationSearch with CustomField Summary: Ref T2625. Ref T3794. Ref T418. Ref T1703. This is a more general version of D5278. It expands CustomField support to include real integration with ApplicationSearch. Broadly, custom fields may elect to: - build indicies when objects are updated; - populate ApplicationSearch forms with new controls; - read inputs entered into those controls out of the request; and - apply constraints to search queries. Some utility/helper stuff is provided to make this easier. This part could be cleaner, but seems reasonable for a first cut. In particular, the Query and SearchEngine must manually call all the hooks right now instead of everything happening magically. I think that's fine for the moment; they're pretty easy to get right. Test Plan: I added a new searchable "Company" field to People: {F58229} This also cleaned up the disable/reorder view a little bit: {F58230} As it did before, this field appears on the edit screen: {F58231} However, because it has `search`, it also appears on the search screen: {F58232} When queried, it returns the expected results: {F58233} And the actually good bit of all this is that the query can take advantage of indexes: mysql> explain SELECT * FROM `user` user JOIN `user_customfieldstringindex` `appsearch_0` ON `appsearch_0`.objectPHID = user.phid AND `appsearch_0`.indexKey = 'mk3Ndy476ge6' AND `appsearch_0`.indexValue IN ('phacility') ORDER BY user.id DESC LIMIT 101; +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | 1 | SIMPLE | appsearch_0 | ref | key_join,key_find | key_find | 232 | const,const | 1 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | user | eq_ref | phid | phid | 194 | phabricator2_user.appsearch_0.objectPHID | 1 | | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ 2 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T1703, T2625, T3794 Differential Revision: https://secure.phabricator.com/D6992
2013-09-16 22:44:34 +02:00
'PhabricatorUserCustomFieldNumericIndex' => 'applications/people/storage/PhabricatorUserCustomFieldNumericIndex.php',
'PhabricatorUserCustomFieldStringIndex' => 'applications/people/storage/PhabricatorUserCustomFieldStringIndex.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserDAO' => 'applications/people/storage/PhabricatorUserDAO.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserEditor' => 'applications/people/editor/PhabricatorUserEditor.php',
Disallow email addresses which will overflow MySQL storage Summary: Via HackerOne. An attacker can bypass `auth.email-domains` by registering with an email like: aaaaa...aaaaa@evil.com@company.com We'll validate the full string, then insert it into the database where it will be truncated, removing the `@company.com` part. Then we'll send an email to `@evil.com`. Instead, reject email addresses which won't fit in the table. `STRICT_ALL_TABLES` stops this attack, I'm going to add a setup warning encouraging it. Test Plan: - Set `auth.email-domains` to `@company.com`. - Registered with `aaa...aaa@evil.com@company.com`. Previously this worked, now it is rejected. - Did a valid registration. - Tried to add `aaa...aaaa@evil.com@company.com` as an email address. Previously this worked, now it is rejected. - Did a valid email add. - Added and executed unit tests. Reviewers: btrahan, arice Reviewed By: arice CC: aran, chad Differential Revision: https://secure.phabricator.com/D8308
2014-02-23 19:19:35 +01:00
'PhabricatorUserEditorTestCase' => 'applications/people/editor/__tests__/PhabricatorUserEditorTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserEmail' => 'applications/people/storage/PhabricatorUserEmail.php',
Add rough validation on email addresses Summary: Put a very rough filter on what we'll accept as an email address. We can expand this if anyone is actually using local delivery or other weird things. This is mostly to avoid a theoretical case where some input is parsed differently by `PhutilAddressParser` and the actual mail adapter, in some subtle hypothetical way. This should give us only "reasonable" email addresses which parsers would be hard-pressed to trip up on. Test Plan: Added and executed unit tests. Tried to add silly emails. Added valid emails. Reviewers: btrahan, arice Reviewed By: arice CC: arice, chad, aran Differential Revision: https://secure.phabricator.com/D8320
2014-02-24 02:31:46 +01:00
'PhabricatorUserEmailTestCase' => 'applications/people/storage/__tests__/PhabricatorUserEmailTestCase.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserLog' => 'applications/people/storage/PhabricatorUserLog.php',
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorUserLogView' => 'applications/people/view/PhabricatorUserLogView.php',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorUserPreferences' => 'applications/settings/storage/PhabricatorUserPreferences.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserProfile' => 'applications/people/storage/PhabricatorUserProfile.php',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'applications/people/editor/PhabricatorUserProfileEditor.php',
'PhabricatorUserRealNameField' => 'applications/people/customfield/PhabricatorUserRealNameField.php',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserRolesField' => 'applications/people/customfield/PhabricatorUserRolesField.php',
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',
Merge profile "About" into main profile and simplify some custom field stuff Summary: Ref T1703. Drive "user since" with a custom field and make the other fields render into a property list. Users can make their profiles a little more personal/obnoxious now. Also delete a bunch of code. Test Plan: {F49415} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6401
2013-07-10 14:09:59 +02:00
'PhabricatorUserSinceField' => 'applications/people/customfield/PhabricatorUserSinceField.php',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserStatusField' => 'applications/people/customfield/PhabricatorUserStatusField.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhabricatorUserTestCase' => 'applications/people/storage/__tests__/PhabricatorUserTestCase.php',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'applications/people/customfield/PhabricatorUserTitleField.php',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'applications/people/storage/PhabricatorUserTransaction.php',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'PhabricatorVCSResponse' => 'applications/repository/response/PhabricatorVCSResponse.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Allow tasks to yield to other tasks Summary: For Harbormaster tasks which want to poll or wait, this lets them say "try again a little later" without having to sleep and hold a queue slot. This is basically the same as failing, except that we don't increment the failure counter. Instead, we just set the current lease to the correct length and then exit. The task will be retried after the lease expires. Test Plan: Using both `bin/harbormaster` and `phd debug taskmaster`, ran a lot of waiting tasks through the queue, faking them to either yield or not yield in a controlled manner. The queue responded as expected, yielding tasks appropraitely and retrying them later. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8792
2014-04-16 22:02:12 +02:00
'PhabricatorWorkerYieldException' => 'infrastructure/daemon/workers/exception/PhabricatorWorkerYieldException.php',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyDiscoveryTestCase.php',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyPullTestCase.php',
'PhabricatorWorkingCopyTestCase' => 'applications/repository/engine/__tests__/PhabricatorWorkingCopyTestCase.php',
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 build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'PhameCelerityResources' => 'applications/phame/celerity/PhameCelerityResources.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed 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',
Use application PHIDs in Phlux Summary: Ref T2715. PVAR -> app phids Test Plan: Used `conduit.query` to load one. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6557
2013-07-24 23:06:50 +02:00
'PhluxPHIDTypeVariable' => 'applications/phlux/phid/PhluxPHIDTypeVariable.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
'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 event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'PholioActionMenuEventListener' => 'applications/pholio/event/PholioActionMenuEventListener.php',
Add a defualt view policy for Pholio Summary: Similar to D8110, but for Pholio. Also an IRC user request. Test Plan: Set setting to something unusual, created a new mock. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D8111
2014-01-30 20:53:42 +01:00
'PholioCapabilityDefaultView' => 'applications/pholio/capability/PholioCapabilityDefaultView.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',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioImageHistoryController' => 'applications/pholio/controller/PholioImageHistoryController.php',
'PholioImageQuery' => 'applications/pholio/query/PholioImageQuery.php',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioImageUploadController' => 'applications/pholio/controller/PholioImageUploadController.php',
Show 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',
Use ApplicationSearch in Pholio Summary: Ref T2637. Ref T2625. Convert Pholio to use ApplicationSearch. Test Plan: Viewed mocks, changed filters. Verified edit page works and no longer has a weird side nav on it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2637 Differential Revision: https://secure.phabricator.com/D6530
2013-07-22 21:21:15 +02:00
'PholioMockSearchEngine' => 'applications/pholio/query/PholioMockSearchEngine.php',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockViewController' => 'applications/pholio/controller/PholioMockViewController.php',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioPHIDTypeImage' => 'applications/pholio/phid/PholioPHIDTypeImage.php',
Use application PHIDs in Pholio Mocks Summary: Ref T2715. Switch mocks to the new stuff. Test Plan: Used `phid.query` and `phid.lookup` to find mocks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6517
2013-07-21 21:40:51 +02:00
'PholioPHIDTypeMock' => 'applications/pholio/phid/PholioPHIDTypeMock.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',
Pholio - support editing images - fixes T3489 Summary: Nice title. We add three new transactions - IMAGE_FILE, IMAGE_NAME, and IMAGE_DESCRIPTION. The first is a bit like subscribers as it is a list of file phids. The latter have values of the form ($file_phid => $data), where $data is $name or $description respectively. This is because we need to collate transactions based on $file_phid... Overall, this uses the _underyling files_ and not the "PholioImage" to determine if things are unique or not. That said, simply mark PholioImages as obsolete so inline comments about no-longer applicable PholioImages don't break. Does a reasonable job implementing the mock. Note you can't "update" an image at this time, though you can delete and add at will. Test Plan: played with pholio a ton. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3489 Differential Revision: https://secure.phabricator.com/D6441
2013-07-16 22:31:20 +02:00
'PholioUploadedImageView' => 'applications/pholio/view/PholioUploadedImageView.php',
Phortune v0 Summary: Ref T2787. This does very little so far, but makes inroads on accounts and billing. This is mostly just modeled on what Stripe looks like. The objects are: - **Account**: Has one or more authorized users, who can make manage the account. An example might be "Phacility", and the three of us would be able to manage it. A user may be associated with more than one account (e.g., a corporate account and a personal account) but the UI tries to simplify the common case of a single account. - **Payment Method**: Something we can get sweet sweet money from; for now, a credit card registered with Stripe. Payment methods are associated with an account. - **Product**: A good (one time charge) or service (recurring charge). This might be "t-shirt" or "enterprise plan" or "hourly support" or whatever else. - **Purchase**: Represents a user purchasing a Product for an Account, using a Payment Method. e.g., you bought a shirt, or started a plan, or purchased support. - **Charge**: Actual charges against payment methods. A Purchase can create more than one charge if it's a plan, or if the first charge fails and we re-bill. This doesn't fully account for stuff like coupons/discounts yet but they should fit into the model without any issues. This only implements `Account`, and that only partially. Test Plan: {F37531} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2787 Differential Revision: https://secure.phabricator.com/D5435
2013-03-28 17:10:34 +01:00
'PhortuneAccount' => 'applications/phortune/storage/PhortuneAccount.php',
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',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentBrowseController' => 'applications/phragment/controller/PhragmentBrowseController.php',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentCapabilityCanCreate' => 'applications/phragment/capability/PhragmentCapabilityCanCreate.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentController' => 'applications/phragment/controller/PhragmentController.php',
'PhragmentCreateController' => 'applications/phragment/controller/PhragmentCreateController.php',
'PhragmentDAO' => 'applications/phragment/storage/PhragmentDAO.php',
'PhragmentFragment' => 'applications/phragment/storage/PhragmentFragment.php',
'PhragmentFragmentQuery' => 'applications/phragment/query/PhragmentFragmentQuery.php',
'PhragmentFragmentVersion' => 'applications/phragment/storage/PhragmentFragmentVersion.php',
'PhragmentFragmentVersionQuery' => 'applications/phragment/query/PhragmentFragmentVersionQuery.php',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentHistoryController' => 'applications/phragment/controller/PhragmentHistoryController.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPHIDTypeFragment' => 'applications/phragment/phid/PhragmentPHIDTypeFragment.php',
'PhragmentPHIDTypeFragmentVersion' => 'applications/phragment/phid/PhragmentPHIDTypeFragmentVersion.php',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentPHIDTypeSnapshot' => 'applications/phragment/phid/PhragmentPHIDTypeSnapshot.php',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentPatchController' => 'applications/phragment/controller/PhragmentPatchController.php',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPatchUtil' => 'applications/phragment/util/PhragmentPatchUtil.php',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentPolicyController' => 'applications/phragment/controller/PhragmentPolicyController.php',
Implement "Revert to Version" functionality in Phragment Summary: This functionality allows users to revert a fragment to a previous version from the history page. Reverting a version actually creates a new version pointing at the same file as the version being "reverted" to. In this sense it acts pretty much like Git and other distributed VCS where once you have published a commit the only way to undo your changes is to create a new commit that reverts those changes. Test Plan: Reverted a fragment to a version before it was deleted, then reverted it to when it was deleted and saw the new versions have the correct file PHIDs (including null for the deletion). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7738
2013-12-08 21:57:53 +01:00
'PhragmentRevertController' => 'applications/phragment/controller/PhragmentRevertController.php',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentSnapshot' => 'applications/phragment/storage/PhragmentSnapshot.php',
'PhragmentSnapshotChild' => 'applications/phragment/storage/PhragmentSnapshotChild.php',
'PhragmentSnapshotChildQuery' => 'applications/phragment/query/PhragmentSnapshotChildQuery.php',
'PhragmentSnapshotCreateController' => 'applications/phragment/controller/PhragmentSnapshotCreateController.php',
'PhragmentSnapshotDeleteController' => 'applications/phragment/controller/PhragmentSnapshotDeleteController.php',
'PhragmentSnapshotPromoteController' => 'applications/phragment/controller/PhragmentSnapshotPromoteController.php',
'PhragmentSnapshotQuery' => 'applications/phragment/query/PhragmentSnapshotQuery.php',
'PhragmentSnapshotViewController' => 'applications/phragment/controller/PhragmentSnapshotViewController.php',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentUpdateController' => 'applications/phragment/controller/PhragmentUpdateController.php',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentVersionController' => 'applications/phragment/controller/PhragmentVersionController.php',
Implement "Download ZIP" controller for Phragment Summary: Depends on D7727. This adds support for downloading a fragment and all it's children as a ZIP file. Fragments that have children automatically become directories in the ZIP file. Test Plan: Downloaded a fragment as a ZIP and was able to extract the contents successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7728
2013-12-07 03:25:22 +01:00
'PhragmentZIPController' => 'applications/phragment/controller/PhragmentZIPController.php',
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',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
'PhrequentSearchEngine' => 'applications/phrequent/query/PhrequentSearchEngine.php',
Make Phrequent time accounting aware of the stack Summary: Ref T3569. Fixes T3567. When figuring out how much time has been spent on an object, subtract "preemptive" events which interrupted the object. Also, make the UI look vaguely sane: {F72773} Test Plan: Added a bunch of unit tests, mucked around in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, skyronic, aran Maniphest Tasks: T3567, T3569 Differential Revision: https://secure.phabricator.com/D7349
2013-10-18 21:47:36 +02:00
'PhrequentTimeBlock' => 'applications/phrequent/storage/PhrequentTimeBlock.php',
'PhrequentTimeBlockTestCase' => 'applications/phrequent/storage/__tests__/PhrequentTimeBlockTestCase.php',
Implemented Phrequent time tracking functionality. Summary: This differential implements Phrequent's time tracking functionality for users and hooks it up to Maniphest. It also includes a basic "Time Tracked" list for the Phrequent application, where users can review what they've spent time working on. Test Plan: Apply the patch and track some things in Maniphest. They should appear in the "Time Tracked" view of Phrequent. There is also a `phrequent.show-prompt` option which toggles whether to display a prompt when tracking time. I'm unsure of whether the prompt is useful or is more likely to cause people to click "Track Time", go off and do the task and then come back to the prompt still waiting for them to confirm. A potential solution to the "accidentally clicking the button and recording 2 seconds of time" might be to show a prompt on stop if the total time is under 10 seconds, asking whether the user wants to keep or discard the tracked time. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2857 Differential Revision: https://secure.phabricator.com/D5479
2013-03-30 17:32:29 +01:00
'PhrequentTrackController' => 'applications/phrequent/controller/PhrequentTrackController.php',
'PhrequentTrackableInterface' => 'applications/phrequent/interface/PhrequentTrackableInterface.php',
'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',
Use modern UI elements and application/event-oriented construction in Projects Summary: Ref T2715. This partially modernizes projects. Precursor to using ApplicationSearch, which is a precursor to using application PHIDs. Then, some day, we will make projects good. Test Plan: {F51126} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6524
2013-07-22 18:01:22 +02:00
'PhrictionActionMenuEventListener' => 'applications/phriction/event/PhrictionActionMenuEventListener.php',
Move files in Phabricator one level up Summary: - `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`. - [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php` - Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`. NOTE: `arc diff` timed out so I'm pushing it without review. Test Plan: /D1234 Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general. Auditors: epriestley Maniphest Tasks: T1103
2012-06-01 21:10:26 +02:00
'PhrictionChangeType' => 'applications/phriction/constants/PhrictionChangeType.php',
'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',
Use application PHIDs in Phriction Summary: Ref T2715. Moves Phriction to application PHIDs. Test Plan: Used `phid.query`; browsed Phriction. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6553
2013-07-24 20:32:13 +02:00
'PhrictionPHIDTypeDocument' => 'applications/phriction/phid/PhrictionPHIDTypeDocument.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',
Add breadcrumbs and ApplicationSearch to Phriction Summary: Fixes T3631. Also adds ApplicationSearch. Test Plan: Viewed "New", "Edit"; saw breadcrumbs. Viewed "index", saw application search. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T3631 Differential Revision: https://secure.phabricator.com/D6593
2013-07-28 03:26:42 +02:00
'PhrictionSearchEngine' => 'applications/phriction/query/PhrictionSearchEngine.php',
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',
'PonderAnswer' => 'applications/ponder/storage/PonderAnswer.php',
Restore comments on Ponder answers Summary: Ref T3373. This is still pretty messy: - The JS bugs out a bit with multiple primary object PHIDs on a single page. I'll fix this in a followup. - The comment form itself is enormous, I'll restore some show/hide stuff in a followup. Test Plan: Added answer comments in Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6608
2013-07-29 02:40:11 +02:00
'PonderAnswerCommentController' => 'applications/ponder/controller/PonderAnswerCommentController.php',
Allow ponder answers to be edited Summary: Ref T3373. Use applicationtransactions to edit ponder answers. Also enable tokens and subscriptions. Test Plan: edited an answer Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6607
2013-07-29 02:23:04 +02:00
'PonderAnswerEditController' => 'applications/ponder/controller/PonderAnswerEditController.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerEditor' => 'applications/ponder/editor/PonderAnswerEditor.php',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderAnswerHistoryController' => 'applications/ponder/controller/PonderAnswerHistoryController.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerQuery' => 'applications/ponder/query/PonderAnswerQuery.php',
'PonderAnswerSaveController' => 'applications/ponder/controller/PonderAnswerSaveController.php',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderAnswerTransaction' => 'applications/ponder/storage/PonderAnswerTransaction.php',
'PonderAnswerTransactionComment' => 'applications/ponder/storage/PonderAnswerTransactionComment.php',
Make Ponder use ApplicationTransaction rendering for answers Summary: Ref T3373. This breaks some stuff, but future diffs will fix it. Test Plan: Viewed some questions, saw answer text. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6604
2013-07-29 01:17:51 +02:00
'PonderAnswerTransactionQuery' => 'applications/ponder/query/PonderAnswerTransactionQuery.php',
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',
'PonderCommentQuery' => 'applications/ponder/query/PonderCommentQuery.php',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderConstants' => 'applications/ponder/constants/PonderConstants.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderController' => 'applications/ponder/controller/PonderController.php',
'PonderDAO' => 'applications/ponder/storage/PonderDAO.php',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderEditor' => 'applications/ponder/editor/PonderEditor.php',
Use Application PHIDs for ANSW Summary: Ref T2715. Ref T3578. - Use Application PHIDs for Ponder Answers. - Make Ponder answers policy-aware. - Make PonderAnswerQuery policy-aware. Test Plan: Used `phid.query`; browsed Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6582
2013-07-26 22:19:49 +02:00
'PonderPHIDTypeAnswer' => 'applications/ponder/phid/PonderPHIDTypeAnswer.php',
Use Application PHIDs in Ponder Summary: Ref T2715. Switch Ponder to the new IDs. Test Plan: Ran `phid.lookup`; `phid.query`. Grepped for old constant Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6554
2013-07-24 20:32:31 +02:00
'PonderPHIDTypeQuestion' => 'applications/ponder/phid/PonderPHIDTypeQuestion.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestion' => 'applications/ponder/storage/PonderQuestion.php',
Restore Ponder question commenting Summary: Ref T3373. Same issues as the other commenting patch; it's huge and the JS is a bit buggy. Backend is fine, though. Test Plan: Made some comments on a question. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6610
2013-07-29 02:58:34 +02:00
'PonderQuestionCommentController' => 'applications/ponder/controller/PonderQuestionCommentController.php',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionEditController' => 'applications/ponder/controller/PonderQuestionEditController.php',
move ponder writes into editors; better search indexing Summary: * Moved the remaining `->save()` calls into editors * for the `PonderQuestion`, separate `attachRelated` (needed for indexing and viewing) from `attachVotes` (needed for viewing but not indexing) * Update the indexer to include comment and answer content in the search index. Test Plan: Stuff works as before. Also: add a comment or answer with some easily-identifiable text and search for it; observe that it gets indexed appropriately. Reviewers: epriestley, nh, vrana Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1869 Differential Revision: https://secure.phabricator.com/D3654
2012-10-07 23:35:01 +02:00
'PonderQuestionEditor' => 'applications/ponder/editor/PonderQuestionEditor.php',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderQuestionHistoryController' => 'applications/ponder/controller/PonderQuestionHistoryController.php',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionListController' => 'applications/ponder/controller/PonderQuestionListController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'applications/ponder/mail/PonderQuestionMailReceiver.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionQuery' => 'applications/ponder/query/PonderQuestionQuery.php',
Restore mail to Ponder Summary: Ref T3578. Use ApplicationTransactions mail. Test Plan: {F52159} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578 Differential Revision: https://secure.phabricator.com/D6620
2013-07-29 17:38:25 +02:00
'PonderQuestionReplyHandler' => 'applications/ponder/mail/PonderQuestionReplyHandler.php',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionSearchEngine' => 'applications/ponder/query/PonderQuestionSearchEngine.php',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderQuestionStatus' => 'applications/ponder/constants/PonderQuestionStatus.php',
'PonderQuestionStatusController' => 'applications/ponder/controller/PonderQuestionStatusController.php',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderQuestionTransaction' => 'applications/ponder/storage/PonderQuestionTransaction.php',
'PonderQuestionTransactionComment' => 'applications/ponder/storage/PonderQuestionTransactionComment.php',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionTransactionQuery' => 'applications/ponder/query/PonderQuestionTransactionQuery.php',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionViewController' => 'applications/ponder/controller/PonderQuestionViewController.php',
Pre-prepare for hovercards Summary: D5120 and followups refactor and generalize object references in Remarkup -- notably, they move remarkup rules from a central location to the implementing applications. Preserve blame by doing moves/renames only first. This change moves application remarkup rules into those applications, and renames the ones D5120 modifies. Test Plan: Typed some preview text into a textarea, got a valid Remarkup render. Reviewers: vrana, chad Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5123
2013-02-26 23:57:41 +01:00
'PonderRemarkupRule' => 'applications/ponder/remarkup/PonderRemarkupRule.php',
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',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderTransactionFeedStory' => 'applications/ponder/feed/PonderTransactionFeedStory.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
'PonderVotableInterface' => 'applications/ponder/storage/PonderVotableInterface.php',
'PonderVotableView' => 'applications/ponder/view/PonderVotableView.php',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderVote' => 'applications/ponder/constants/PonderVote.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
'PonderVoteEditor' => 'applications/ponder/editor/PonderVoteEditor.php',
'PonderVoteSaveController' => 'applications/ponder/controller/PonderVoteSaveController.php',
Project work boards - make editing tasks from workboards work Summary: This wasn't working. Create a little JS handler and server-side support for returning the Task in the "project card" format. Test Plan: Edited tasks from the board - they worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D8392
2014-03-04 20:50:44 +01:00
'ProjectBoardTaskCard' => 'applications/project/view/ProjectBoardTaskCard.php',
Add a 'create' policy to Project Summary: UX on this could probably be better 'disabled' crumbs don't appear to have any visible difference, and the policy error has to load the /create page rather than being a modal - not sure on the way to fix these. Test Plan: Tried to create a project with and without access, saw suitable error. Reviewers: epriestley, #blessed_reviewers CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7279
2013-10-10 13:29:07 +02:00
'ProjectCapabilityCreateProjects' => 'applications/project/capability/ProjectCapabilityCreateProjects.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
'ReleephAuthorFieldSpecification' => 'applications/releeph/field/specification/ReleephAuthorFieldSpecification.php',
'ReleephBranch' => 'applications/releeph/storage/ReleephBranch.php',
'ReleephBranchAccessController' => 'applications/releeph/controller/branch/ReleephBranchAccessController.php',
'ReleephBranchCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephBranchCommitFieldSpecification.php',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchController' => 'applications/releeph/controller/branch/ReleephBranchController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchCreateController' => 'applications/releeph/controller/branch/ReleephBranchCreateController.php',
'ReleephBranchEditController' => 'applications/releeph/controller/branch/ReleephBranchEditController.php',
'ReleephBranchEditor' => 'applications/releeph/editor/ReleephBranchEditor.php',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchHistoryController' => 'applications/releeph/controller/branch/ReleephBranchHistoryController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchNamePreviewController' => 'applications/releeph/controller/branch/ReleephBranchNamePreviewController.php',
'ReleephBranchPreviewView' => 'applications/releeph/view/branch/ReleephBranchPreviewView.php',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephBranchQuery' => 'applications/releeph/query/ReleephBranchQuery.php',
Use ApplicationSearch for Releeph branch lists Summary: Releeph branch lists in project views have a bunch of custom UI right now; give them more standard UI and ApplicationSearch. This drops a small piece of functionality: we now show only a total open request count instead of a detailed enumeration of each request status. I assume this is reasonable (that is, the important piece is "is there something to do on this branch?"), but we can muck with it if the more detailed status is important. Test Plan: {F54344} Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3656 Differential Revision: https://secure.phabricator.com/D6764
2013-08-17 03:55:35 +02:00
'ReleephBranchSearchEngine' => 'applications/releeph/query/ReleephBranchSearchEngine.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchTemplate' => 'applications/releeph/view/branch/ReleephBranchTemplate.php',
Remove ReleephBranchBoxView Summary: Ref T3092. This was obsoleted recently and has no more call/use sites. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6779
2013-08-20 18:31:27 +02:00
'ReleephBranchTransaction' => 'applications/releeph/storage/ReleephBranchTransaction.php',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchTransactionQuery' => 'applications/releeph/query/ReleephBranchTransactionQuery.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchViewController' => 'applications/releeph/controller/branch/ReleephBranchViewController.php',
'ReleephCommitFinder' => 'applications/releeph/commitfinder/ReleephCommitFinder.php',
'ReleephCommitFinderException' => 'applications/releeph/commitfinder/ReleephCommitFinderException.php',
'ReleephCommitMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephCommitMessageFieldSpecification.php',
'ReleephController' => 'applications/releeph/controller/ReleephController.php',
'ReleephDAO' => 'applications/releeph/storage/ReleephDAO.php',
'ReleephDefaultFieldSelector' => 'applications/releeph/field/selector/ReleephDefaultFieldSelector.php',
Add dependencies to releeph Summary: Add the 'Depends On' field to releeph requests. This will help the release engineers to be aware of the dependencies and make sure pick them altogether. Test Plan: Check sandbox. This field shows up when a revision has some dependencies. Reviewers: JoelB, lifeihuang, epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7946
2014-01-14 03:18:26 +01:00
'ReleephDependsOnFieldSpecification' => 'applications/releeph/field/specification/ReleephDependsOnFieldSpecification.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephDiffChurnFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffChurnFieldSpecification.php',
'ReleephDiffMessageFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffMessageFieldSpecification.php',
'ReleephDiffSizeFieldSpecification' => 'applications/releeph/field/specification/ReleephDiffSizeFieldSpecification.php',
'ReleephFieldParseException' => 'applications/releeph/field/exception/ReleephFieldParseException.php',
'ReleephFieldSelector' => 'applications/releeph/field/selector/ReleephFieldSelector.php',
'ReleephFieldSpecification' => 'applications/releeph/field/specification/ReleephFieldSpecification.php',
'ReleephIntentFieldSpecification' => 'applications/releeph/field/specification/ReleephIntentFieldSpecification.php',
'ReleephLevelFieldSpecification' => 'applications/releeph/field/specification/ReleephLevelFieldSpecification.php',
'ReleephOriginalCommitFieldSpecification' => 'applications/releeph/field/specification/ReleephOriginalCommitFieldSpecification.php',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephPHIDTypeBranch' => 'applications/releeph/phid/ReleephPHIDTypeBranch.php',
Rename Releeph "Project" PHID type to "Product" Summary: Ref T3549. Test Plan: `grep`, loaded some pages Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8811
2014-04-19 02:52:45 +02:00
'ReleephPHIDTypeProduct' => 'applications/releeph/phid/ReleephPHIDTypeProduct.php',
Use application handle infrastructure for Releeph Requests and Releeph Projects Summary: Ref T2715. Test Plan: Used `phid.query` to query handles. Browsed Releeph. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6510
2013-07-21 17:41:38 +02:00
'ReleephPHIDTypeRequest' => 'applications/releeph/phid/ReleephPHIDTypeRequest.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductActionController' => 'applications/releeph/controller/product/ReleephProductActionController.php',
'ReleephProductController' => 'applications/releeph/controller/product/ReleephProductController.php',
'ReleephProductCreateController' => 'applications/releeph/controller/product/ReleephProductCreateController.php',
'ReleephProductEditController' => 'applications/releeph/controller/product/ReleephProductEditController.php',
Use ApplicationTransactions for Releeph product activity Summary: Ref T3549. Ref T3663. - Use transactions for activate/deactivate. - Rename some "project" -> "product". Test Plan: - Activated products. - Deactivated products. {F135480} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3663, T3549 Differential Revision: https://secure.phabricator.com/D8634
2014-03-29 17:16:02 +01:00
'ReleephProductEditor' => 'applications/releeph/editor/ReleephProductEditor.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductHistoryController' => 'applications/releeph/controller/product/ReleephProductHistoryController.php',
'ReleephProductListController' => 'applications/releeph/controller/product/ReleephProductListController.php',
Rename ReleephProjectQuery to ReleephProductQuery Summary: Ref T3549. Test Plan: grep/lint Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8815
2014-04-20 20:51:02 +02:00
'ReleephProductQuery' => 'applications/releeph/query/ReleephProductQuery.php',
Rename more project -> product in Releeph Summary: Ref T3549. - Renames most "project" in view/list controllers. - Moves away from "ProjectController". - Modernizes some modern UI. Test Plan: - Viewed product lists. - Viewed product detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8635
2014-03-29 17:16:24 +01:00
'ReleephProductSearchEngine' => 'applications/releeph/query/ReleephProductSearchEngine.php',
Rename Releeph "Project" transactions to "Product" Summary: Ref T3549. This table isn't written to yet; rename it and the DAOs and modernize the history controller. Test Plan: Viewed history page for a product. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8633
2014-03-29 17:15:09 +01:00
'ReleephProductTransaction' => 'applications/releeph/storage/ReleephProductTransaction.php',
'ReleephProductTransactionQuery' => 'applications/releeph/query/ReleephProductTransactionQuery.php',
Move /project/ controllers to /product/ Summary: Ref T3549. Move only, no extra changes. Test Plan: Loaded application. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8817
2014-04-20 20:54:37 +02:00
'ReleephProductViewController' => 'applications/releeph/controller/product/ReleephProductViewController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephProject' => 'applications/releeph/storage/ReleephProject.php',
'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',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestController' => 'applications/releeph/controller/request/ReleephRequestController.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestDifferentialCreateController' => 'applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php',
'ReleephRequestEditController' => 'applications/releeph/controller/request/ReleephRequestEditController.php',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'applications/releeph/mail/ReleephRequestMailReceiver.php',
Add unit tests to cover PhabricatorMailReceiver::matchAddresses() Summary: Ref T3183. We should accept addresses like `"New Bug" <bugs@example.com>` to match `bugs@example.com`. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3183 Differential Revision: https://secure.phabricator.com/D5923
2013-05-15 00:04:17 +02:00
'ReleephRequestQuery' => 'applications/releeph/query/ReleephRequestQuery.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestReplyHandler' => 'applications/releeph/mail/ReleephRequestReplyHandler.php',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
'ReleephRequestSearchEngine' => 'applications/releeph/query/ReleephRequestSearchEngine.php',
ReleephRequestStatus Summary: This is just a bit of gardening in order to make the responsive-UI diff easier; I'll be putting `getColorFor($status)` type things in this class, following the pattern in `ManiphestTaskStatus`. Test Plan: Poke around Releeph. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D5893
2013-05-10 18:07:33 +02:00
'ReleephRequestStatus' => 'applications/releeph/constants/ReleephRequestStatus.php',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'applications/releeph/storage/ReleephRequestTransaction.php',
'ReleephRequestTransactionComment' => 'applications/releeph/storage/ReleephRequestTransactionComment.php',
'ReleephRequestTransactionQuery' => 'applications/releeph/query/ReleephRequestTransactionQuery.php',
'ReleephRequestTransactionalEditor' => 'applications/releeph/editor/ReleephRequestTransactionalEditor.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'applications/releeph/view/request/ReleephRequestTypeaheadControl.php',
'ReleephRequestTypeaheadController' => 'applications/releeph/controller/request/ReleephRequestTypeaheadController.php',
Use standard UI elements to render pull requests in Releeph Summary: Ref T3718. Ref T3644. Ref T3092. Switches from the Releeph UI elements to standard ones. I'll attach some screenshots. Also fixes CSRF against the request action endpoint. Test Plan: - Viewed request details. - Took actions on a request from detail page. - Viewed request list. - Took actions on a request from list page. - Used keyboard shortcuts to navigate list. - Used keyboard shortcuts to take actions. - Simulated errors. - Viewed on devices. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: grp, FacebookPOC, mattlqx, tala, beng, LegNeato, epriestley Maniphest Tasks: T3718, T3092, T3644 Differential Revision: https://secure.phabricator.com/D8771
2014-04-18 15:44:45 +02:00
'ReleephRequestView' => 'applications/releeph/view/ReleephRequestView.php',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestViewController' => 'applications/releeph/controller/request/ReleephRequestViewController.php',
'ReleephRequestorFieldSpecification' => 'applications/releeph/field/specification/ReleephRequestorFieldSpecification.php',
'ReleephRevisionFieldSpecification' => 'applications/releeph/field/specification/ReleephRevisionFieldSpecification.php',
'ReleephSeverityFieldSpecification' => 'applications/releeph/field/specification/ReleephSeverityFieldSpecification.php',
'ReleephSummaryFieldSpecification' => 'applications/releeph/field/specification/ReleephSummaryFieldSpecification.php',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'ShellLogView' => 'applications/harbormaster/view/ShellLogView.php',
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',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'SubscriptionListDialogBuilder' => 'applications/subscriptions/view/SubscriptionListDialogBuilder.php',
'SubscriptionListStringBuilder' => 'applications/subscriptions/view/SubscriptionListStringBuilder.php',
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',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'_phabricator_time_format' => '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
'celerity_generate_unique_node_id' => 'infrastructure/celerity/api.php',
'celerity_get_resource_uri' => 'infrastructure/celerity/api.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_selected_handle_links' => 'applications/phid/handle/view/render.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_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',
Pholio - support editing images - fixes T3489 Summary: Nice title. We add three new transactions - IMAGE_FILE, IMAGE_NAME, and IMAGE_DESCRIPTION. The first is a bit like subscribers as it is a list of file phids. The latter have values of the form ($file_phid => $data), where $data is $name or $description respectively. This is because we need to collate transactions based on $file_phid... Overall, this uses the _underyling files_ and not the "PholioImage" to determine if things are unique or not. That said, simply mark PholioImages as obsolete so inline comments about no-longer applicable PholioImages don't break. Does a reasonable job implementing the mock. Note you can't "update" an image at this time, though you can delete and add at will. Test Plan: played with pholio a ton. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3489 Differential Revision: https://secure.phabricator.com/D6441
2013-07-16 22:31:20 +02:00
'AphrontAbstractAttachedFileView' => 'AphrontView',
Javelin integration.
2011-01-25 20:57:47 +01:00
'AphrontAjaxResponse' => '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
'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',
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',
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',
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',
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',
Improve accessibility of some UI elements (forms, icons, timeline) Summary: Ref T4843. Chips away at a few more things. Test Plan: Used VoiceOver and got a generally more sensible-seeming result. Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4843 Differential Revision: https://secure.phabricator.com/D8978
2014-05-05 17:16:35 +02:00
'AphrontFormSectionControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSelectControl' => 'AphrontFormControl',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'AphrontFormStaticControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormSubmitControl' => 'AphrontFormControl',
'AphrontFormTextAreaControl' => 'AphrontFormControl',
'AphrontFormTextControl' => 'AphrontFormControl',
Clean up the Diffusion search UI a little bit Summary: Ref T156. @vlada recently implemented filename search in Diffusion, this cleans up the UI a little bit: - Instead of showing one search box with two different buttons, let the submit buttons appear to the right of the text boxes and separate the search modes. - Clean up the results a little bit (don't show columns which don't exist). Test Plan: {F107260} Reviewers: vlada, btrahan, chad Reviewed By: chad CC: vlada, chad, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8125
2014-02-01 20:48:28 +01:00
'AphrontFormTextWithSubmitControl' => 'AphrontFormControl',
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',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'AphrontFormTypeaheadControl' => 'AphrontFormControl',
Import some code, some of which may be relevant to the project.
2011-01-16 22:51:39 +01:00
'AphrontFormView' => 'AphrontView',
AphrontBars Summary: Aphront widgets that render the either a discrete or continuous value as a horizontal shape. Like a progress bar, or a five-star rating bar. Test Plan: `/uiexample/view/PhabricatorAphrontBarExample/` ...which shows this, amongst other things: {F33898} Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D5122
2013-03-05 17:46:09 +01:00
'AphrontGlyphBarView' => 'AphrontBarView',
Make webpage response final
2012-11-29 08:57:13 +01:00
'AphrontHTMLResponse' => 'AphrontResponse',
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',
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',
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',
When stopping on redirect, show a full stack trace Summary: Ref T4140. Provide more debugging information so we can figure out what's going on with redirect loops. Test Plan: {F83868} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4140 Differential Revision: https://secure.phabricator.com/D7620
2013-11-21 23:38:29 +01:00
'AphrontStackTraceView' => 'AphrontView',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'AuditActionMenuEventListener' => 'PhabricatorEventListener',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'CalendarColors' => 'CalendarConstants',
Fix calendar display on profile. Summary: ...maybe anyway because I can't reproduce it live. This diff does two things that should help with bugginess though - uses $viewer rather than $user (...$user is who we are looking at...) *AND* upgrades a Conpherence util class to Calendar, and said util class has unit tests and came about from fixing a similar bug in Conpherence back in the day. Wrote some comments in the util class because I think it has a tendency to trip people up. These comments are not partciularly good however. Test Plan: viewed user profile - looked good. viewed conpherence - looked good. ran unit tests - they passed. (note I would also like to push this live and verify Chad's profile is fixed on secure.phabricator.com) Reviewers: epriestley, chad Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8341
2014-02-25 22:43:31 +01:00
'CalendarTimeUtilTestCase' => 'PhabricatorTestCase',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityManagementMapWorkflow' => 'CelerityManagementWorkflow',
'CelerityManagementWorkflow' => 'PhabricatorManagementWorkflow',
Allow blog resources to be served without Celerity Summary: Allow skins to serve arbitrary resources without needing to be mapped, so we can have a vibrant community of amateur skinners. For "basic" skins, just put all the "css/" on the page always. Includes an image to prove that works. @vrana, pretty sure this has no impact outside of Phame but it does change Celerity so it might be to blame if there's any weirdness with static resources. Test Plan: {F21341} {F21340} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1373 Differential Revision: https://secure.phabricator.com/D3719
2012-10-17 17:37:05 +02:00
'CelerityPhabricatorResourceController' => 'CelerityResourceController',
Begin construction of `bin/celerity map` Summary: Ref T4222. Moves us toward a more modern Celerity CLI, and moves map discovery into the classtree. This is a little bit bulky (and means you can't ship completely standalone celerity maps) but has the advantage of being completely standard, and we could subclass maps into an auto-discovering map later if we have a need for it. This doesn't affect the existing Celerity stuff. I'm going to build the new stuff in parallel, and then swap us over at the end. Test Plan: Ran `bin/celerity map`, got reasonable-looking output. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7864
2014-01-01 03:02:41 +01:00
'CelerityPhabricatorResources' => 'CelerityResourcesOnDisk',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'CelerityPhysicalResources' => 'CelerityResources',
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',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'CelerityResourcesOnDisk' => 'CelerityPhysicalResources',
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'ConduitAPIMethod' =>
array(
0 => 'Phobject',
1 => 'PhabricatorPolicyInterface',
),
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',
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',
Remove DifferentialCommentEditor and DifferentialCommentMail Summary: Ref T2222. These no longer have any callsites. Also got rid of a little bit of other code which also no longer has callsites. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8443
2014-03-08 02:44:19 +01:00
'ConduitAPI_differential_close_Method' => 'ConduitAPI_differential_Method',
Allow Conduit console to be browsed by logged-out users Summary: Ref T4830. A few methods, like `conduit.ping`, are callable without authentication, so this even has some use cases. Also: - Make some Differential stuff a little more consistent. - Use slightly more modern rendering. - Deprecate the status-oriented `user` calls; these will be replaced by Calendar methods. Test Plan: Browsed console as logged out / logged in users. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4830 Differential Revision: https://secure.phabricator.com/D8826
2014-04-22 00:32:48 +02:00
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPI_differential_Method',
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',
Remove DifferentialRevisionEditor Summary: Ref T2222. This has no callsites and no functionality not present in the TransactionEditor. Test Plan: awwyiss Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8456
2014-03-08 21:15:29 +01:00
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPI_differential_Method',
Allow Conduit console to be browsed by logged-out users Summary: Ref T4830. A few methods, like `conduit.ping`, are callable without authentication, so this even has some use cases. Also: - Make some Differential stuff a little more consistent. - Use slightly more modern rendering. - Deprecate the status-oriented `user` calls; these will be replaced by Calendar methods. Test Plan: Browsed console as logged out / logged in users. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4830 Differential Revision: https://secure.phabricator.com/D8826
2014-04-22 00:32:48 +02:00
'ConduitAPI_differential_find_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_finishpostponedlinters_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_getrawdiff_Method' => 'ConduitAPI_differential_Method',
Use CustomFields to power Conduit auxiliary dictionaries Summary: Ref T2222. Moves this Conduit stuff over. Test Plan: Made Conduit calls, saw data in results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8469
2014-03-09 19:23:55 +01:00
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPI_differential_Method',
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',
Allow Conduit console to be browsed by logged-out users Summary: Ref T4830. A few methods, like `conduit.ping`, are callable without authentication, so this even has some use cases. Also: - Make some Differential stuff a little more consistent. - Use slightly more modern rendering. - Deprecate the status-oriented `user` calls; these will be replaced by Calendar methods. Test Plan: Browsed console as logged out / logged in users. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4830 Differential Revision: https://secure.phabricator.com/D8826
2014-04-22 00:32:48 +02:00
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPI_differential_Method',
Use CustomFields to power Conduit auxiliary dictionaries Summary: Ref T2222. Moves this Conduit stuff over. Test Plan: Made Conduit calls, saw data in results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8469
2014-03-09 19:23:55 +01:00
'ConduitAPI_differential_query_Method' => 'ConduitAPI_differential_Method',
Allow Conduit console to be browsed by logged-out users Summary: Ref T4830. A few methods, like `conduit.ping`, are callable without authentication, so this even has some use cases. Also: - Make some Differential stuff a little more consistent. - Use slightly more modern rendering. - Deprecate the status-oriented `user` calls; these will be replaced by Calendar methods. Test Plan: Browsed console as logged out / logged in users. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4830 Differential Revision: https://secure.phabricator.com/D8826
2014-04-22 00:32:48 +02:00
'ConduitAPI_differential_querydiffs_Method' => 'ConduitAPI_differential_Method',
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPI_differential_Method',
Remove DifferentialRevisionEditor Summary: Ref T2222. This has no callsites and no functionality not present in the TransactionEditor. Test Plan: awwyiss Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8456
2014-03-08 21:15:29 +01:00
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPI_differential_Method',
Allow Conduit console to be browsed by logged-out users Summary: Ref T4830. A few methods, like `conduit.ping`, are callable without authentication, so this even has some use cases. Also: - Make some Differential stuff a little more consistent. - Use slightly more modern rendering. - Deprecate the status-oriented `user` calls; these will be replaced by Calendar methods. Test Plan: Browsed console as logged out / logged in users. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4830 Differential Revision: https://secure.phabricator.com/D8826
2014-04-22 00:32:48 +02:00
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPI_differential_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_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 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',
Add "diffusion.createcomment" conduit endpoint Summary: Adds most of Diffusion's commenting options available in the web UI Mark method as deprecated immediately per @epriestley's request Test Plan: Used the Conduit web console to check: * Lookup by PHID works * Error is raised if commit by PHID is not found * "action" validation works and raises appropriate error * "message" raises error if empty * Actions to raise concern or accept commit work * Method is marked as deprecated from the start Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6923
2013-09-09 23:25:08 +02:00
'ConduitAPI_diffusion_createcomment_Method' => 'ConduitAPI_diffusion_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',
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',
Show additional status information during repository import Summary: Ref T2350. Fixes T2231. - Adds log flags around discovery. - Adds message flags for "needs update". This is basically an out-of-band hint to the daemons that a repository should be pulled sooner than normal. We set the flag when users push a revision, and expose a Conduit method that `arc land` will be able to use. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2350, T2231 Differential Revision: https://secure.phabricator.com/D7467
2013-10-31 23:46:57 +01:00
'ConduitAPI_diffusion_looksoon_Method' => 'ConduitAPI_diffusion_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',
Add `diffusion.querycommits` and deprecate `diffusion.getcommits` Summary: Fixes T4344. `diffusion.getcommits` is nasty old bad news. Implement a modern query method. This method provides limit/paging in a somewhat abstract way so it's sort of ultramodern, but I didn't want the default behavior to return a million rows. I'll probably move more stuff toward this over time, now that cursor paging is pervasive. Here, we needed extra metadata (the identifier map) anyway. Test Plan: Used console to execute command. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4344 Differential Revision: https://secure.phabricator.com/D8077
2014-01-28 02:14:21 +01:00
'ConduitAPI_diffusion_querycommits_Method' => 'ConduitAPI_diffusion_Method',
Basic filename search support for Diffusion Summary: Ref T156. Adds basic filename search support for Diffusion, currently only for Git repositories. This is preliminary, and it's up for discussion: - is the UI in the right place; - what should the search query syntax be (e.g. whether to put `*`s in the beginning and end of it); - how to best approach it for Mercurial and/or SVN; - what's the cleanest result format for `lsquery` (I went for the minimum necessary change to `DiffusionBrowseSearchController`). Test Plan: Browse to a repository in Diffusion, and use both `Search File Names` and `Search File Content`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T156 Differential Revision: https://secure.phabricator.com/D8093
2014-02-01 17:32:23 +01:00
'ConduitAPI_diffusion_querypaths_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',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'ConduitAPI_diffusion_resolverefs_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 - 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',
Provide a rough, unstable API for reporting coverage into Diffusion Summary: Ref T4994. This stuff works: - You can dump a blob of coverage information into `diffusion.updatecoverage`. This wipes existing coverage information and replaces it. - It shows up when viewing files. - It shows up when viewing commits. This stuff does not work: - When viewing files, the Javascript hover interaction isn't tied in yet. - We always show this information, even if you're behind the commit where it was generated. - You can't do incremental updates. - There's no aggregation at the file (this file has 90% coverage), diff (the changes in this commit are 90% covered), or directory (the code in this directory has 90% coverage) levels yet. - This is probably not the final form of the UI, storage, or API, so you should expect occasional changes over time. I've marked the method as "Unstable" for now. Test Plan: - Ran `save_lint.php` to check for collateral damage; it worked fine. - Ran `save_lint.php` on a new branch to check creation. - Published some fake coverage information. - Viewed an affected commit. - Viewed an affected file. {F151915} {F151916} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley, zeeg Maniphest Tasks: T5044, T4994 Differential Revision: https://secure.phabricator.com/D9022
2014-05-18 01:10:54 +02:00
'ConduitAPI_diffusion_updatecoverage_Method' => 'ConduitAPI_diffusion_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',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'ConduitAPI_harbormaster_Method' => 'ConduitAPIMethod',
Add a rough `harbormaster.querybuildables` Conduit API method Summary: Ref T4809. I need to sort out some of the "status" stuff we're doing before this is actually useful (there's no sensible "status" value to expose right now) but once that happens `arc` can query this to figure out whether it needs to warn the user about pending/failed builds. Test Plan: Ran query with various different parameters. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8794
2014-04-18 01:00:25 +02:00
'ConduitAPI_harbormaster_querybuildables_Method' => 'ConduitAPI_harbormaster_Method',
Add "harbormaster.querybuilds" Conduit API Summary: Ref T4809. This one is more straightforward. A couple of tweaks: - Remove the WAITING status, since nothing ever sets it and I suspect nothing ever will with the modern way artifacts work (maybe). At a minimum, it's confusing with the new Target status that's also called "WAITING" but means something different. - Consolidate 17 copies of these status names into one method. Test Plan: Ran some queries via Conduit, got reasonable looking results. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8795
2014-04-18 01:00:58 +02:00
'ConduitAPI_harbormaster_querybuilds_Method' => 'ConduitAPI_harbormaster_Method',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'ConduitAPI_harbormaster_sendmessage_Method' => 'ConduitAPI_harbormaster_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',
Adding macro create method.
2013-06-08 00:08:34 +02:00
'ConduitAPI_macro_creatememe_Method' => 'ConduitAPI_macro_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_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',
Maniphest - add conduit method to get status information Summary: Ref T4938. `arc close` needs to know about custom statuses and this conduit method is step 1 of letting it know Test Plan: See next diff, which works! Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4938 Differential Revision: https://secure.phabricator.com/D8937
2014-05-02 01:11:39 +02:00
'ConduitAPI_maniphest_querystatuses_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',
Nuance - conduit method to create items Summary: pretty simple. did the bare minimum in the editor, etc. to be able to create an item from the conduit console. I put the work in the editor for initializing new values, rather than some initializeNewItem method, mainly because Items don't have policy directly but instead policy will be defined by the queue(s) the item is in. The editor is definitely going to host this work, so it felt like it might be better to do it this way in time...? anyway, easy to make an initializeNew method instead if you want to have that paradigm going all the time. Test Plan: made an item from teh conduit console - success. verified errors for missing data as well Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7879
2014-01-06 20:19:32 +01:00
'ConduitAPI_nuance_Method' => 'ConduitAPIMethod',
'ConduitAPI_nuance_createitem_Method' => 'ConduitAPI_nuance_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 phame.queryblog and phame.querypost Conduit calls. Summary: This implements Conduit calls for querying Phame blogs and Phame posts. Test Plan: Made some calls and they seem to generally work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D7478
2013-11-03 00:31:30 +01:00
'ConduitAPI_phame_Method' => 'ConduitAPIMethod',
Phame - create conduit API to create posts Summary: nothing too crazy here. try to be smart about some defaults (i.e. phame title is optional and can be derived from title; post as not a draft by default; etc). Fixes T3695. also do a little re-factoring to centralizing initializing new posts and turning posts into dictionaries. also change blogs => posts in another conduit method so it makes sense and stuff. Test Plan: made some posts via conduit. testing trying to specify blogger, phame title, and isDraft, all worked nicely Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D8485
2014-03-11 23:51:53 +01:00
'ConduitAPI_phame_createpost_Method' => 'ConduitAPI_phame_Method',
Add phame.queryblog and phame.querypost Conduit calls. Summary: This implements Conduit calls for querying Phame blogs and Phame posts. Test Plan: Made some calls and they seem to generally work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3695 Differential Revision: https://secure.phabricator.com/D7478
2013-11-03 00:31:30 +01:00
'ConduitAPI_phame_query_Method' => 'ConduitAPI_phame_Method',
'ConduitAPI_phame_queryposts_Method' => 'ConduitAPI_phame_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',
Provide `phragment.getstate` and `phragment.getpatch` Conduit methods Summary: This provides a `phragment.getstate` and a `phragment.getpatch` Conduit method. `phragment.getstate` - This returns the current state of the fragment and all of it's children. `phragment.getpatch` - This accepts a base path and a mapping of paths to hashes. The mapping is for the caller to specify the current state of the files it has. This returns a list of patches that the caller needs to apply to it's files to get to the latest version. Test Plan: Ran the following script in a folder which had content matching a fragment and it's children: ``` #!/bin/bash STATE="" for i in $(find ./ -type f); do HASH=$(cat $i | sha1sum | awk '{ print $1 }') BASE=${i:2} STATE="$STATE,\"$BASE\":\"$HASH\"" done STATE=${STATE:1} STATE="{$STATE}" echo '{"path":"tychaia3.zip","state":'$STATE'}' | arc --conduit-uri=http://phabricator.local/ call-conduit phragment.getpatch ``` and I got: ``` {"error":null,"errorMessage":null,"response":[]} ``` I updated one of the child fragments with a new file and ran the script again (patch has been omitted due to it's size): ``` {"error":null,"errorMessage":null,"response":[{"path":"Content\/TitleFont.xnb","hash_old":"4a927d7b90582e50cdd330de9f4b59b0cc5eb5c7","hash_new":"25867504642a3a403102274c68fbb9b430c1980f","patch":"..."}]} ``` Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, staticshock Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7739
2013-12-11 01:19:23 +01:00
'ConduitAPI_phragment_Method' => 'ConduitAPIMethod',
'ConduitAPI_phragment_getpatch_Method' => 'ConduitAPI_phragment_Method',
'ConduitAPI_phragment_queryfragments_Method' => 'ConduitAPI_phragment_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 modern releeph.queryproducts and releeph.querybranches Summary: Ref T3662. Ref T3549. These methods are pretty conservative for now, but get the structure in place. Also do a bunch more project -> product stuff. Test Plan: Made calls to both methods, browsed around the UI a fair amount. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549, T3662 Differential Revision: https://secure.phabricator.com/D8816
2014-04-20 20:54:22 +02:00
'ConduitAPI_releeph_querybranches_Method' => 'ConduitAPI_releeph_Method',
'ConduitAPI_releeph_queryproducts_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_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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitConnectionGarbageCollector' => 'PhabricatorGarbageCollector',
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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'ConduitLogGarbageCollector' => 'PhabricatorGarbageCollector',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ConpherenceActionMenuEventListener' => 'PhabricatorEventListener',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ConpherenceHovercardEventListener' => 'PhabricatorEventListener',
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',
Conpherence - add dropdown menu Summary: Fixes T3641. Probably needs some @chad love though on colors and what have you. Technique was to jam this into the existing notifications stuff as much as possible. I think its "okay" but if we were to add more stuff here (like a 3rd application) this could get a quality pass to consolidate even more code. Test Plan: played with it in Chrome and Safari - looks reasonable Reviewers: chad, epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3641 Differential Revision: https://secure.phabricator.com/D6708
2013-08-08 22:43:33 +02:00
'ConpherenceNotificationPanelController' => 'ConpherenceController',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipant' => 'ConpherenceDAO',
Conpherence - paginate thread list Summary: this is D5750 but just the conpherence part. fixes a few random conpherence bugs / quirks as well. Also messes with ApplicationTransactionEditor to expose the xactions so Conpherence doesn't over-update participation rows. Fixes T2429. Test Plan: set LIMIT to 3. verified I could scroll down all conpherences. next, picked a conpherence "in the middle" to load. verified I could page up and down. next, picked a conpherence in the middle then had another user update that conpherence. verified as I paged up the conpherence re-loaded properly selected Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin, vrana Maniphest Tasks: T2429 Differential Revision: https://secure.phabricator.com/D5783
2013-04-26 19:30:41 +02:00
'ConpherenceParticipantCountQuery' => 'PhabricatorOffsetPagedQuery',
Conpherence V1 Summary: it's ugly. but it works. basically. See T2399 for a roughly prioritized list of what still needs to happen. Test Plan: - created a conpherence with myself from my profile - created a conpherence with myself from "new conpherence" - created a conphernece with another from "new conpherence" - created a conpherence with several others - created a conpherence with files in the initial post - verified files via comment text ("{F232} is awesome!") and via traditional attach - edited a conpherence image - verified it showed up in the header and in the conpherence menu on the left - edited a conpherence title - verified it showed up in the header and in the conpherence menu on the right - verified each widget showed up when clicked and displayed the proper data - calendar being an exception since it sucks so hard right now. Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, epriestley, chad, codeblock, Korvin Maniphest Tasks: T2301 Differential Revision: https://secure.phabricator.com/D4620
2013-01-25 02:23:05 +01:00
'ConpherenceParticipantQuery' => 'PhabricatorOffsetPagedQuery',
'ConpherenceParticipationStatus' => 'ConpherenceConstants',
Conpherence - people widget Summary: adds ye olde people widget. Features include - handle-based display, so we get status for free. (Note less pretty than M14 would have it!) - can add a person - can remove a person - can see the people already in the conpherence Test Plan: added and removed people and noted they joined / re-added as appropriate. Tried to add someone already in the conpherence and got a "transaction has no effect" message Reviewers: epriestley, chad Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2399 Differential Revision: https://secure.phabricator.com/D5466
2013-04-02 18:32:40 +02:00
'ConpherencePeopleWidgetView' => 'ConpherenceWidgetView',
Conpherence - 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',
'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',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DarkConsoleEventPluginAPI' => 'PhabricatorEventListener',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DifferentialActionMenuEventListener' => 'PhabricatorEventListener',
AddCommentView
2011-01-30 20:02:22 +01:00
'DifferentialAddCommentView' => 'AphrontView',
Build an "affected path" index when attaching diffs to revisions Summary: See T262. This creates the index on the Differential side which we need in order to execute this query efficiently on the Diffusion side. Also renames "DiffusionGitPathIDQuery" to "DiffusionPathIDQuery", this query object has nothing to do with git. Test Plan: Attached top-level and sub-level diffs to revisions and verified they populated the table with sensible data. Reviewers: bmaurer, aravindn, fmoo, jungejason, nh, tuomaspelkonen, aran CC: Differential Revision: 931
2011-09-14 19:59:52 +02:00
'DifferentialAffectedPath' => 'DifferentialDAO',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialApplyPatchField' => 'DifferentialCustomField',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialArcanistProjectField' => 'DifferentialCustomField',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAsanaRepresentationField' => 'DifferentialCustomField',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialAuditorsField' => 'DifferentialStoredCustomField',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialAuthorField' => 'DifferentialCustomField',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialBlameRevisionField' => 'DifferentialStoredCustomField',
Add Branch and Arcanist Project CustomFields Summary: Ref T2222. These are pretty straightforward. For these fields and a few others, the existing code shows the value for the "current/manual" diff (i.e., the diff selected in the diff selection table), not the "active" diff (i.e., the most recent diff attached to the revision). I'm going to drop that for now (always showing the most recent diff instead) and then reevaluate it once we're switched over. In 95% of cases these are the same, anyway. Test Plan: Looked at fields; this diff changes nothing on its own. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8359
2014-02-27 20:05:48 +01:00
'DifferentialBranchField' => 'DifferentialCustomField',
Add a "default view" policy to Differential Summary: Ref T603. Allows the Differential view policy to be configured with a default. I've omitted "edit" because I want to wait and see how comment/comment-action policies work out. I could imagine locking "edit" down to only the owner at some point, and providing a wider "interact" capability, or something like that, which would cover accept/reject/commandeer. Users in this group could still edit indirectly by commandeering first. Test Plan: Created new revisions from the CLI and conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7269
2013-10-09 22:58:00 +02:00
'DifferentialCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Restore "Branch" and "changes since last update" fields to Differential mail Summary: Ref T418. Fixes T4642. The "changes since last update" and "branch" fields got dropped; restore them in a general, field-driven way. Test Plan: - Created a revision, got relevant sections in mail. - Commented on a revision, got relevant sections in mail. - Updated a revision, got relevant sections in mail. Reviewers: btrahan Reviewed By: btrahan Subscribers: spicyj, epriestley Maniphest Tasks: T418, T4642 Differential Revision: https://secure.phabricator.com/D8657
2014-04-01 17:23:34 +02:00
'DifferentialChangesSinceLastUpdateField' => 'DifferentialCustomField',
Move more hunk loads into DifferentialHunkQuery Summary: Ref T5179. Ref T4045. I want to move all hunk loads into DifferentialHunkQuery so I can make it do magical things where hunks come from multiple places, handle non-utf8 encodings properly, handle compression, archive into Files, and so on. Test Plan: Viewed some revisions. Called `differential.getrawdiff`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9287
2014-05-25 17:09:01 +02:00
'DifferentialChangeset' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorPolicyInterface',
),
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',
Introduce DifferentialChangesetQuery and remove loadHunks() Summary: Ref T4045. Ref T5179. This removes all non-Query hunk loads. Test Plan: - Viewed revisions. - Viewed standalone changesets. - Viewed raw old/new files. - Viewed vs diffs. - Enabled inline comments in mail and sent some transactions with inlines. - Called `differential.getrawdiff`. - Grepped for `loadHunks()`. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9289
2014-05-25 17:59:31 +02:00
'DifferentialChangesetQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialChangesetTestRenderer' => 'DifferentialChangesetRenderer',
'DifferentialChangesetTwoUpRenderer' => 'DifferentialChangesetHTMLRenderer',
'DifferentialChangesetTwoUpTestRenderer' => 'DifferentialChangesetTestRenderer',
DifferentialChangesetView
2011-01-25 00:52:35 +01:00
'DifferentialChangesetViewController' => 'DifferentialController',
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 commit message parsing to a separate, tested class Summary: Ref T2222. We have a hunk of logic that purely does text parsing here; separate it and get coverage on it. Test Plan: - Ran new unit tests. - Used `differential.parsecommitmessage`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8444
2014-03-08 02:44:35 +01:00
'DifferentialCommitMessageParserTestCase' => 'PhabricatorTestCase',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialCommitsField' => 'DifferentialCustomField',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialConflictsField' => 'DifferentialCustomField',
DifferentialDiffView
2011-01-24 22:18:41 +01:00
'DifferentialController' => 'PhabricatorController',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialCoreCustomField' => 'DifferentialCustomField',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialCustomField' => 'PhabricatorCustomField',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'DifferentialCustomFieldDependsOnParser' => 'PhabricatorCustomFieldMonogramParser',
'DifferentialCustomFieldDependsOnParserTestCase' => 'PhabricatorTestCase',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
Bring "Reverts X" to more general infrastructure and port unit tests Summary: Ref T3886. See D8261. This brings the "reverts x" phrase to modern infrastructure. It isn't actually called by the real parser yet, I'm going to do that in one go at the end so I can test everything more easily. This had unit tests; port most of them forward. Test Plan: Added and executed unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8262
2014-02-18 00:58:59 +01:00
'DifferentialCustomFieldRevertsParser' => 'PhabricatorCustomFieldMonogramParser',
'DifferentialCustomFieldRevertsParserTestCase' => 'PhabricatorTestCase',
Adjust keys for new Differential inline comment table Summary: Ref T2222. This sequences //before// D7139 and sorts out keys on the table. In particular: - There was a fairly silly `draft` key modeled after Pholio; drop it. - Add a `revisionPHID` key. This is queried mostly-transitionally on the revision view screen. - Add a `changesetID` key. This is queried by a bunch of interfaces that want more surgical results than `revisionPHID` provides. - Add an `authorPHID, transactionPHID` key. This is queried on the list interface to find pending drafts. - Add a `legacy` key. This is queried by the feed publisher. Test Plan: Used the query analyzer to hit all (I think?) of the pages, saw keyed queries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D7140
2013-09-26 22:48:36 +02:00
'DifferentialCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'DifferentialCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Conduit: differential.creatediff
2011-01-24 20:01:53 +01:00
'DifferentialDAO' => 'PhabricatorLiskDAO',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialDependenciesField' => 'DifferentialCustomField',
'DifferentialDependsOnField' => 'DifferentialCustomField',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
'DifferentialDiff' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorPolicyInterface',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
2 => 'HarbormasterBuildableInterface',
Implement PhabricatorApplicationTransactionInterface in Differential Summary: Ref T4810. Ultimate goal is to let Harbormaster post a "build passed/failed" transaction. To prepare for that, implement `PhabricatorApplicationTransactionInterface` in Differential. To allow Harbormaster to take action on //diffs// but have the transactions apply to //revisions//, I added a new method so that objects can redirect transactions to some other object. Test Plan: - Subscribed/unsubscribed/attached/detached from Differential, saw transactions appear properly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4810 Differential Revision: https://secure.phabricator.com/D8802
2014-04-18 01:03:24 +02:00
3 => 'PhabricatorApplicationTransactionInterface',
Allow structured destruction of Differential Revisions Summary: Ref T4749. Ref T3265. Ref T4909. - Remove old "destroy revision" script. - Move to structured `bin/remove` destruction. - Fix some edge issues. - Add transaction destruction support. Test Plan: - Destroyed a bunch of revisions. - Saw diffs, changesets, hunks, transactions, edges, and inlines also get wiped out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4749, T4909, T3265 Differential Revision: https://secure.phabricator.com/D8943
2014-05-02 03:25:30 +02:00
4 => 'PhabricatorDestructableInterface',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
),
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',
Add DifferentialDiffQuery and change most callsites Summary: Ref T603. This introduces a policy-aware DifferentialDiffQuery and converts most callsites. I've left unusual callsites (mostly: hard to get the viewer, unusual query, queries related to active diffs) alone for now, so this isn't exhaustive but hits 60-80% of sites. Test Plan: Created diff; created revision; viewed diffs and revisions; made additional conduit calls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6338
2013-07-01 21:38:42 +02:00
'DifferentialDiffQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Generalize Asana-publishable feed story objects Summary: Ref T2852. Pulls the Differential-specific aspects of the Asana sync out of the worker. Next diff will add a publisher for Audit/Diffusion. Test Plan: Published events, including state changes. Saw them reflected correctly in Asana. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6569
2013-07-26 17:56:35 +02:00
'DifferentialDoorkeeperRevisionFeedStoryPublisher' => 'DoorkeeperFeedStoryPublisher',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'DifferentialDraft' => 'DifferentialDAO',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialEditPolicyField' => 'DifferentialCoreCustomField',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'DifferentialFieldParseException' => 'Exception',
'DifferentialFieldValidationException' => 'Exception',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialGitSVNIDField' => 'DifferentialCustomField',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialHostField' => 'DifferentialCustomField',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DifferentialHovercardEventListener' => 'PhabricatorEventListener',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
'DifferentialHunk' =>
array(
0 => 'DifferentialDAO',
1 => 'PhabricatorPolicyInterface',
),
Add an alternate "modern" hunk datastore Summary: Ref T4045. Ref T5179. Hunk storage has two major issues: - It's utf8, but actual diffs are binary. - It's huge and can't be compressed or archived. This introduces a second datastore which solves these problems: by recording hunk encoding, supporting compression, and supporting alternate storage. There's no actual compression or storage support yet, but there's space in the table for them. Since nothing actually uses hunk IDs, it's fine to have these tables exist at the same time and use the same IDs. We can migrate data between the tables gradually without requiring downtime or disrupting installs. Test Plan: - There are no writes to the new table yet. - The only effect this has is making us issue one extra query when looking for hunks. - Observed the query issue, but everything else continue working fine. - Created a new diff. - Ran unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9290
2014-05-25 18:28:11 +02:00
'DifferentialHunkLegacy' => 'DifferentialHunk',
'DifferentialHunkModern' => 'DifferentialHunk',
re-factor DifferentialChangesetParser pass 3 / N Summary: introducing a new friend called DifferentialHunkParser. Sort of like the DifferentialChangesetParser but works with hunks only. tried to grab hunk parsing type things from across the code base and move them into this new class. Test Plan: unit tests and played around in Differential a bit. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4351
2013-01-09 22:11:17 +01:00
'DifferentialHunkParserTestCase' => 'PhabricatorTestCase',
Add DifferentialHunkQuery to start hiding hunk storage details Summary: Ref T4045. We have a lot of direct queries against the hunk table right now. These are messy, not really policy-aware, and limit our options on T4045. This query is unusual (it requires changesets, and does not accept IDs). This keeps us from having to load changeset -> diff -> revision in order to do policy checks. We could also fix this with smarter policy checks and caching, but I'd rather not open that can of worms for now. This object is very low level and relatively unusual, and this small deviation from convention seems like the cleanest cut to make to keep this from snowballing. Test Plan: Used Herald dry runs to verify that the affected rules still output the same data. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045 Differential Revision: https://secure.phabricator.com/D8765
2014-04-14 21:06:26 +02:00
'DifferentialHunkQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Add printable support to CSS Summary: Fixes T2146. This is a really simple approach, you just do: !print .rule { whatever: blah; } And it transforms it into: .printable .rule { whatever: blah; } @media print { .rule { whatever: blah; } } So we end up with these rules twice, but they should compress well and we shouldn't need that many of them, and this fix is way way simpler than all the nonsense I discussed in T2146. Test Plan: - Added a unit test. - Added a simple rule to throw away the menubar when printing. - Checked the latter with `/?__print__=1`. Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Maniphest Tasks: T2146 Differential Revision: https://secure.phabricator.com/D7363
2013-10-19 23:23:19 +02:00
'DifferentialInlineComment' => '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',
Abstract access to DifferentialInlineComment behind a Query Summary: Ref T2222. See D6260. Push all this junk behind a Query so I can move the storage out from underneath it. Test Plan: Viewed home page, list view, revision. Made draft, looked at preview, submitted draft, viewed inline, replied to inline. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6262
2013-06-21 21:54:56 +02:00
'DifferentialInlineCommentQuery' => 'PhabricatorOffsetPagedQuery',
InlineComments
2011-02-02 01:42:36 +01:00
'DifferentialInlineCommentView' => 'AphrontView',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialJIRAIssuesField' => 'DifferentialStoredCustomField',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingActionMenuEventListener' => 'PhabricatorEventListener',
Land to GitHub + support stuff Summary: A usable, Land to GitHub flow. Still to do: - Refactor all git/hg stratagies to a sane structure. - Make the dialogs Workflow + explain why it's disabled. - Show button and request Link Account if GH is enabled, but user is not linked. - After refreshing token, user ends up in the settings stage. Hacked something in LandController to be able to show an arbitrary dialog from a strategy. It's not very nice, but I want to make some more refactoring to the controller/strategy/ies anyway. Also made PhabricatorRepository::getRemoteURIObject() public, because it was very useful in getting the domain and path for the repo. Test Plan: Went through these flows: - load revision in hosted, github-backed, non-github backed repos to see button as needed. - hit land with weak token - sent to refresh it with the extra scope. - Land to repo I'm not allowed - got proper error message. - Successfully landed; Failed to apply patch. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7555
2013-11-14 02:25:14 +01:00
'DifferentialLandingToGitHub' => 'DifferentialLandingStrategy',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialLandingToHostedGit' => 'DifferentialLandingStrategy',
Add support for landing to hosted Mercurial repos. Summary: I've kept this as close as possible to the Git version for ease of review and later refactoring of them both together. At minimum, the functions to get the working dir should probably be cleaned up one day. Test Plan: Landed a revision. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7534
2013-11-08 20:37:57 +01:00
'DifferentialLandingToHostedMercurial' => 'DifferentialLandingStrategy',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialLintField' => 'DifferentialCustomField',
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',
Remove DifferentialRevisionEditor Summary: Ref T2222. This has no callsites and no functionality not present in the TransactionEditor. Test Plan: awwyiss Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8456
2014-03-08 21:15:29 +01:00
'DifferentialManiphestTasksField' => 'DifferentialCoreCustomField',
Assign PHIDs to all diffs Summary: Ref T1049. Ref T2222. `DifferentialDiff` does not currently have a PHID, but we need it for Harbormaster and ApplicationTransactions. See some discussion in D7501. (I split the SQL into two sections so we can't fail in the middle. At some point, I'd like to do a pass on the migration stuff and get this happening automatically, and also simplify the PatchList.) Test Plan: - Ran `bin/storage upgrade`. - Checked for valid PHIDs in the database. - Used `phid.query` to look up a diff by PHID. - Created a new diff and verified it got a PHID. Reviewers: btrahan, hach-que Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2222, T1049 Differential Revision: https://secure.phabricator.com/D7513
2013-11-06 22:59:06 +01:00
'DifferentialPHIDTypeDiff' => 'PhabricatorPHIDType',
Move DifferentialRevision to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.lookup` and `phid.query` to load handles. Grepped for `PHID_TYPE_DREV`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6509
2013-07-21 17:11:37 +02:00
'DifferentialPHIDTypeRevision' => 'PhabricatorPHIDType',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'DifferentialParseCacheGarbageCollector' => 'PhabricatorGarbageCollector',
Implement basic one-up and test renderers Summary: This is a half-step toward one-up and test renderers. This is mostly a structural change, and has no user-facing impact. It splits the rendering hierarchy like this: - Renderer (more methods are abstract than before) - HTML Renderer (most HTML stuff has moved down from the base to here) - HTML 1-up (placeholder only -- not yet a functional implementation) - HTML 2-up (minimal changes, uses mostly old code) - Test Renderer (unit-testable renderer base, implements text versions of the HTML stuff) - Test 1-up (selects 1-up mode for test rendering) - Test 2-up (selects 2-up mode for test rendering) Broadly, I'm trying to share as much code as possible by splitting rendering into more, smaller stages. Specifically, we do this: - Combine the various sorts of inputs (changes, context, inlines, etc.) into a single, relatively homogenous list of "primitives". This happens in the base class. - The primitive types are: old (diff left side), new (diff right side), context ("show more context"), no-context ("context not available") and inline (inline comment). - Possibly, apply a filtering/reordering step to the primitives to get them ready for 1-up rendering. This mostly removes information, and does a small amount of reordering. This also happens in the base class. - Pass the primitives to the actual renderer, to convert them into HTML, text, or whatever else. This happens in the leaf class. The primitive implementation is not yet complete (it doesn't attach as much information to the primitives as it should -- stuff like coverage and copies), but covers the basics. The existing HTMLTwoUp renderer does not use the primitive path; instead, it still goes down the old path. Test Plan: Ran unit tests, looked at a bunch of diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2009 Differential Revision: https://secure.phabricator.com/D4421
2013-01-14 23:20:06 +01:00
'DifferentialParseRenderTestCase' => 'PhabricatorTestCase',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialPathField' => 'DifferentialCustomField',
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',
Implement detail views for many Differential fields on ApplicationTransactions Summary: Ref T2222. This isn't complete and doesn't change runtime behavior yet (the new fields are not glued to the interface), but implements many fields. (The remaining fields have something weird going on with them, for the most part.) Test Plan: With additional changes, rendered most fields sensibly: {F118834} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8354
2014-02-26 23:46:18 +01:00
'DifferentialProjectReviewersField' => 'DifferentialCustomField',
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',
Implement "Repository" as a new-style CustomField in Differential Summary: Ref T3886. Ref T418. - Adds new capabilities for CustomField: - Controls can now bulk-load PHIDs (e.g., for tokenizers). - Transactions can now bulk-load PHIDs (e.g., for relationship changes). - Implements "Repository" control. - Improves tokenizer StandardCustomField controls. Test Plan: {F115942} {F115943} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8286
2014-02-21 20:53:37 +01:00
'DifferentialRepositoryField' => 'DifferentialCoreCustomField',
When creating or updating a revision, infer the repository from the diff Summary: Ref T603. When a diff is attached to a revision, try to guess the repository if possible. In cases where we succeed, this automatically gives us intuitive policy behavior (i.e., you can see a revision if you can see the repository the change is against). I pulled this into a funky little "Lookup" class for two reasons: - It's used in two places; - I anticipate that we might need to add some sort of `explainWhy()` method if users find the heuristics confusing. Test Plan: Created and updated revisions, saw them pick up the correct repository association. Ran Herald dry run against associable and nonassociable revisions, saw correct values populate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7147
2013-09-27 00:28:42 +02:00
'DifferentialRepositoryLookup' => 'Phobject',
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',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialRevertPlanField' => 'DifferentialStoredCustomField',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialReviewedByField' => 'DifferentialCoreCustomField',
Implement a "Reviewers" CustomField Summary: Ref T3886: - Adds a "Reviewers" field as a modern CustomField. Ref T418: - Allows CustomFields to emit transaction metadata. Test Plan: {F116254} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8291
2014-02-21 20:54:32 +01:00
'DifferentialReviewersField' => 'DifferentialCoreCustomField',
Split users apart from projects/packages in reviewer and audit UIs Summary: Ref T1279. Show separate sections for "Reviewers" and "Project Reviewers" (Differential) and for "Auditors" and "Package/Project Auditors" (Diffusion/Audit). Test Plan: - Looked at a commit. Saw separation. - Looked at a revision. Saw separation. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7233
2013-10-05 16:54:42 +02:00
'DifferentialReviewersView' => 'AphrontView',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => 'PhrequentTrackableInterface',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
5 => 'HarbormasterBuildableInterface',
Move Differential to proper subscriptions Summary: Ref T2222. Ref T4415. We're still writing Differential subscription stuff into this weird legacy `differential_relationship` table, which is like an edge table but extremely ancient. Move it into a proper table. I've removed `withSubscriptions()` from `DifferentialRevisionQuery`. It was weird, doesn't work consistently with other similar filters, and was only used by the API. Now it means "ccs", which is consistent with the ApplicationSearch UI and with Maniphest. Test Plan: Without migrating, added and removed subscribers via various workflows. Queried for subscribers. Everything worked as expected. Ran the migration, verified data survived. Reviewers: btrahan Reviewed By: btrahan CC: FacebookPOC, aran Maniphest Tasks: T2222, T4415 Differential Revision: https://secure.phabricator.com/D8202
2014-02-12 17:53:40 +01:00
6 => 'PhabricatorSubscribableInterface',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
7 => 'PhabricatorCustomFieldInterface',
Implement PhabricatorApplicationTransactionInterface in Differential Summary: Ref T4810. Ultimate goal is to let Harbormaster post a "build passed/failed" transaction. To prepare for that, implement `PhabricatorApplicationTransactionInterface` in Differential. To allow Harbormaster to take action on //diffs// but have the transactions apply to //revisions//, I added a new method so that objects can redirect transactions to some other object. Test Plan: - Subscribed/unsubscribed/attached/detached from Differential, saw transactions appear properly. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4810 Differential Revision: https://secure.phabricator.com/D8802
2014-04-18 01:03:24 +02:00
8 => 'PhabricatorApplicationTransactionInterface',
Allow structured destruction of Differential Revisions Summary: Ref T4749. Ref T3265. Ref T4909. - Remove old "destroy revision" script. - Move to structured `bin/remove` destruction. - Fix some edge issues. - Add transaction destruction support. Test Plan: - Destroyed a bunch of revisions. - Saw diffs, changesets, hunks, transactions, edges, and inlines also get wiped out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4749, T4909, T3265 Differential Revision: https://secure.phabricator.com/D8943
2014-05-02 03:25:30 +02:00
9 => 'PhabricatorDestructableInterface',
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
),
DifferentialRevisionView
2011-01-27 23:55:52 +01:00
'DifferentialRevisionDetailView' => 'AphrontView',
RevisionEdit
2011-01-25 22:26:09 +01:00
'DifferentialRevisionEditController' => 'DifferentialController',
Perform commit message parsing and construction with new CustomFields Summary: Ref T2222. Ref T3886. Converts parsing and construction of commit messages to be driven by CustomField. Test Plan: This is a huge, messy change. I've made an effort to test it exhasutively, but suspect I probably missed a few behaviors. Roughly: - Enumerted all current fields (fields implementing `shouldAppearOnCommitMessage()`) and tried to test them one by one. - Used `arc diff --edit` repeatedly to manipulate each field (this workflow hits both the parse and construct steps). - Used `arc amend --show` to examine construct output (this does not activate the "edit" mode). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8449
2014-03-08 02:05:00 +01:00
'DifferentialRevisionIDField' => 'DifferentialCustomField',
Land Revision button for hosted git repos Summary: ref T182. Simple approach of clone, patch, push. While waiting for drydock, implement a hackish mutex setup for the workspace, which should work ok as long as there's only one committer who is carefull about theses things. Less obvious note: This is taking the both author and commiter's 'primary email' for the commit - which might rub some people wrong. Test Plan: With a hosted repo, created some diffs and landed them. Also clicked button for some error cases, got the right error message. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: hach-que, Korvin, epriestley, aran Maniphest Tasks: T182 Differential Revision: https://secure.phabricator.com/D7486
2013-11-05 22:00:12 +01:00
'DifferentialRevisionLandController' => 'DifferentialController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DifferentialRevisionListController' => 'DifferentialController',
Separate revision list rendering logic into a RevisionListView Summary: I want to throw this in Diffusion as part of T262, but it's embedded in the controller right now. Split it out. Test Plan: Looked at various revision list views, no changes. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: jungejason CC: aran, jungejason Differential Revision: 977
2011-10-02 20:42:41 +02:00
'DifferentialRevisionListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'DifferentialRevisionMailReceiver' => 'PhabricatorObjectMailReceiver',
[Rough Sketch] Differential ObjectItemView Smexyness Summary: Tried out `PhabricatorObjectItemView` for Differential. It looks smexy and smooth. Refs T2014 - Title and Date as Maniphest - Author in the handle icon - Bar color reflects revision status (Needs Review, Accepted, Abandoned etc.) @chad looking for non-blue is faster than keeping watch for everything that's not "Closed" in old table form - Some status information are in footer icons; currently only stale/old status display as well as saved drafts, maybe more in future; these come into my mind: - No reviewer warning - Push Blocking Priority (T2730) - Trivial, fast review guaranteed - Sketch / Just looking for advice/help - Arcanist Project (T2614) - Denote "Public Send-in" (T1476) {F37662} {F37663} {F37664} {F37665} Some flaws: - Date and reviewers on every entry the same? - No respect for Differential fields (for some reason, every entry appeared the same, so broke it to parts) - Plenty of (potential) increase in height - advise reducing paging length from 100 to 50 - or just ignore me Suggestions for the future: - Expand the meta information regarding revisions; e.g. the various status displays above - Uh... T2543, T1279, T793, T731 and what else I want for Differential, because they are awesome! - T793 should be in particular easy appearance-wise, just copy-paste from Maniphest Test Plan: By looking at it, of course. Verified there are no errors or crashed Reviewers: epriestley, chad, btrahan, liguobig Reviewed By: chad CC: aran, Korvin, edward, nh Maniphest Tasks: T2014 Differential Revision: https://secure.phabricator.com/D5451 Conflicts: src/__celerity_resource_map__.php
2013-07-02 21:14:33 +02:00
'DifferentialRevisionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Differential Summary: Ref T603. Ref T2625. Fixes T3241. Depends on D5451. Depends on D6346. @wez, this changes the Differential revision list UI substantially and may generate a lot of bikeshedding / who-moved-my-cheese churn. See T3417 for context, for example. The motivations for this change are: - The list now works on devices, like phones and tablets. This is a requirement to make the rest of Differential work on devices. - Although ApplicationSearch intentionally presents a simpler interface initially and some options which were one click away before aren't now, it is much more powerful than the search it replaces and allows users to build, save, share, fork, edit, and customize a much wider range of queries. Users who used the old filters frequently can use Advanced Search -> Save Custom Query to create new versions of them, and of any other query. "Edit Queries.." allows users to remove and reorder queries, including builtin queries. Basically, there are like three things which have gone from "1-click" to "a few clicks", and ten trillion things which have gone from "hard/impossible" to "relatively easy". The local screenshots look a bit iffy, but I think a lot of this is the fakenesss of my test data. If they still feel iffy in production we can tweak them until they feel good, like we did for Maniphest. Test Plan: {F48477} {F48478} Reviewers: btrahan, chad, wez Reviewed By: btrahan CC: aran, s Maniphest Tasks: T603, T2625, T3241 Differential Revision: https://secure.phabricator.com/D6347
2013-07-03 15:11:07 +02:00
'DifferentialRevisionSearchEngine' => 'PhabricatorApplicationSearchEngine',
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',
Implement more Differential fields on ApplicationTransaction/CustomField Summary: Ref T2222. Ref T3886. Gets the storage-based fields working. This requires future changes to actually do anything, all this code is inactive. Test Plan: {F118863} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886, T2222 Differential Revision: https://secure.phabricator.com/D8357
2014-02-27 01:53:42 +01:00
'DifferentialStoredCustomField' => 'DifferentialCustomField',
Implement Differential subscribers as a CustomField Summary: Ref T3886. Now that a custom field can emit a core transaction, just emit a subscribers transaction. Test Plan: {F116014} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8289
2014-02-21 20:54:08 +01:00
'DifferentialSubscribersField' => 'DifferentialCoreCustomField',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialSummaryField' => 'DifferentialCoreCustomField',
Implement "Test Plan" as a CustomField Summary: Ref T3886. Moves some of the "required" logic to the base class ("DifferentialCoreField") so Title and Test Plan can share it. Test Plan: Edited revisions using "pro" editor, saw test plan transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8285
2014-02-21 20:53:27 +01:00
'DifferentialTestPlanField' => 'DifferentialCoreCustomField',
Implement new-style "Summary" field Summary: Ref T3886. - Adds "Summary" field. - Adds "CoreField" for fields stored on the actual object, to reduce code duplication a bit for the main fields. Test Plan: {F115902} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8283
2014-02-21 20:52:52 +01:00
'DifferentialTitleField' => 'DifferentialCoreCustomField',
Add storage for new Differential transactions and transaction comments Summary: Ref T2222. Ref T1460. Depends on D6260. This creates the new tables, but doesn't start using them. I added three new fields for {T1460}, to represent fixed/done/replied states. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1460, T2222 Differential Revision: https://secure.phabricator.com/D6261
2013-06-21 21:54:29 +02:00
'DifferentialTransaction' => 'PhabricatorApplicationTransaction',
'DifferentialTransactionComment' => 'PhabricatorApplicationTransactionComment',
Implement "Pro" version of revision editor, with one field Summary: Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of. Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field. (There are no links to this in the UI.) Test Plan: {F115353} {F115354} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3886 Differential Revision: https://secure.phabricator.com/D8276
2014-02-19 01:32:55 +01:00
'DifferentialTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
Migrate Differential comments to ApplicationTransactions Summary: Ref T2222. This is the big one. This migrates each `DifferentialComment` to one or more ApplicationTransactions (action, cc, reviewers, update, comment, inlines), and makes `DifferentialComment` a double-reader for ApplicationTransactions. The migration is pretty straightforward: - If a comment took an action not otherwise covered, it gets an "action" transaction. This is something like "epriestley abandoned this revision.". - If a comment updated the diff, it gets an "updated diff" transaction. Very old transactions of this type may not have a diff ID (probably only at Facebook). - If a comment added or removed reviewers, it gets a "changed reviewers" transaction. - If a comment added CCs, it gets a "subscribers" transaction. - If a comment added comment text, it gets a "comment" transaction. - For each inline attached to a comment, we generate an "inline" transaction. Most comments generate a small number of transactions, but a few generate a significant number. At HEAD, the code is basically already doing this, so comments in the last day or two already obey these rules, roughly, and will all generate only one transaction (except inlines). Because we've already preallocated PHIDs in the comment text table, we only need to write to the transaction table. NOTE: This significantly degrades Differential, making inline comments pretty much useless (they each get their own transaction, and don't show line numbers or files). The data is all fine, but the UI is garbage now. This needs to be fixed before we can deploy this to users, but it's easily separable since it's all just display code. Specifically, they look like this: {F112270} Test Plan: I've migrated locally and put things through their paces, but it's hard to catch sketchy stuff locally because most of my test data is nonsense and bad migrations wouldn't necessarily look out of place. IMPORTANT: I'm planning to push this to a branch and then shift production over to the branch, and run it for a day or two before bringing it to master. I generally feel good about this change: it's not that big since we were able to separate a lot of pieces out of it, and it's pretty straightforward. That said, it's still one of the most scary/dangerous changes we've ever made. Reviewers: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8210
2014-02-12 00:36:58 +01:00
'DifferentialTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Use timeline view in Differential and make inlines somewhat usable again Summary: Ref T2222. This gets rid of Differential's custom view and uses a standard view instead. This also mostly fixes the rendering logic for inlines. This is headed to the `tmp.differential` branch. Test Plan: {F112696} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T1790, T2222 Differential Revision: https://secure.phabricator.com/D8215
2014-02-12 23:05:40 +01:00
'DifferentialTransactionView' => 'PhabricatorApplicationTransactionView',
Add modern Unit/Lint field support Summary: Ref T2222. This is mostly copy/paste. No effect yet. Test Plan: Looked at fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8360
2014-02-27 20:06:37 +01:00
'DifferentialUnitField' => 'DifferentialCustomField',
Implement view and edit policies in Differential CustomFields Summary: Ref T3886. Ref T418. - Adds "View Policy" and "Edit Policy" fields. - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them. Test Plan: {F116001} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T3886 Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 20:53:48 +01:00
'DifferentialViewPolicyField' => 'DifferentialCoreCustomField',
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',
Improve organization of Diffusion browse controllers Summary: Currently we have this: - DiffusionController (abstract, has some random shared browse code) - DiffusionBrowseController (concrete, Handles routing, directories, and search) - DiffusionBrowseFileController (concrete, handles files) Instead, do this: - DiffusionController (no browse-related code) - DiffusionBrowseController (abstract, shared browse code) - DiffusionBrowseMainController (concrete, handles routing) - DiffusionBrowseDirectoryController (concrete, handles directories) - DiffusionBrowseFileController (concrete, handles files) - DiffusionBrowseSearchController (concrete, handles search) Feels a lot cleaner. Test Plan: Looked at directories, searches, and files. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7045
2013-09-20 01:01:34 +02:00
'DiffusionBrowseDirectoryController' => 'DiffusionBrowseController',
'DiffusionBrowseFileController' => 'DiffusionBrowseController',
'DiffusionBrowseMainController' => 'DiffusionBrowseController',
'DiffusionBrowseSearchController' => 'DiffusionBrowseController',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionBrowseTableView' => 'DiffusionView',
Activate the new Repository creation workflow Summary: Ref T2231. This: - Activates the new multi-step workflow, and exposes it in the UI. - Adds "can create", "default view" and "default edit" capabilities. - Provides a default value for `repository.default-local-path` and forces repositories into it by default. It's still editable, but Phabricator gets it correct (for some definition of correct) by default now. Test Plan: Created some new repositories with the new workflow. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7413
2013-10-26 02:46:08 +02:00
'DiffusionCapabilityCreateRepositories' => 'PhabricatorPolicyCapability',
'DiffusionCapabilityDefaultEdit' => 'PhabricatorPolicyCapability',
Add global "push" policy to Repositories Summary: No editing or view yet, just adds the schema and a policy default. Part of D7391. Test Plan: `bin/storage upgrade` Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7415
2013-10-26 04:12:52 +02:00
'DiffusionCapabilityDefaultPush' => 'PhabricatorPolicyCapability',
Activate the new Repository creation workflow Summary: Ref T2231. This: - Activates the new multi-step workflow, and exposes it in the UI. - Adds "can create", "default view" and "default edit" capabilities. - Provides a default value for `repository.default-local-path` and forces repositories into it by default. It's still editable, but Phabricator gets it correct (for some definition of correct) by default now. Test Plan: Created some new repositories with the new workflow. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7413
2013-10-26 02:46:08 +02:00
'DiffusionCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Add global "push" policy to Repositories Summary: No editing or view yet, just adds the schema and a policy default. Part of D7391. Test Plan: `bin/storage upgrade` Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7415
2013-10-26 04:12:52 +02:00
'DiffusionCapabilityPush' => 'PhabricatorPolicyCapability',
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',
Move commit hash querying to DiffusionLowLevelCommitQuery Summary: Ref T4195. I need this for the Herald pre-commit rules, and it generally simplifies things. Test Plan: Used `reparse.php` plus `var_dump()` to inspect refs in Git, Mercurial and SVN repos. They all looked correct and reparsed correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7804
2013-12-20 21:38:15 +01:00
'DiffusionCommitHash' => 'Phobject',
Install pre-commit hooks in Git repositories Summary: Ref T4189. T4189 describes most of the intent here: - When updating hosted repositories, sync a pre-commit hook into them instead of doing a `git fetch`. - The hook calls into Phabricator. The acting Phabricator user is sent via PHABRICATOR_USER in the environment. The active repository is sent via CLI. - The hook doesn't do anything useful yet; it just veifies basic parameters, does a little parsing, and exits 0 to allow the commit. Test Plan: - Performed Git pushes and pulls over SSH and HTTP. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7682
2013-12-03 00:45:36 +01:00
'DiffusionCommitHookEngine' => 'Phobject',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionCommitHookRejectException' => 'Exception',
Prepare Diffusion for hovercards Summary: Move Diffusion to be hovercard-ready, and expand our ability to resolve commit references. - Link unqualified hashes of 7 characters or more which match a commit. - Link qualified hashes of 5 characters or more which match a commit. - Support `{...}` syntax. Test Plan: {F33896} Reviewers: chad, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D5121
2013-02-27 17:04:54 +01:00
'DiffusionCommitQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move git commit metadata parsing into a LowLevelQuery Summary: Ref T4195. I need to issue this command from the pre-commit hook to get commit bodies for hooks. Test Plan: Ran `reparse.php --message --trace` and dumped the $ref, which looked correct. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7793
2013-12-19 02:48:06 +01:00
'DiffusionCommitRef' => 'Phobject',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionCommitRemarkupRule' => 'PhabricatorRemarkupRuleObject',
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 commits/audits to Asana bridge Summary: Ref T2852. Adds sync for commits/audits. Test Plan: {F51660} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6573
2013-07-26 19:31:35 +02:00
'DiffusionDoorkeeperCommitFeedStoryPublisher' => 'DoorkeeperFeedStoryPublisher',
Add remarkup.process conduit method Summary: This exposes a few remarkup engines over conduit. Test Plan: Local conduit console, and playing with 'cat example.json | arc call-conduit remarkup.process' Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Differential Revision: https://secure.phabricator.com/D1551
2012-02-03 01:42:29 +01:00
'DiffusionEmptyResultView' => 'DiffusionView',
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',
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',
Allow parenthesis in author name Summary: We have a dozen users who has `(...)` in their 'real name', like 'Jimmy (He) Zhang', and it's causing the diffusion file browser problems when blame is enabled. The parser does not expect those parenthesis and the lines of code will be empty if they were last touched by a user like that. Test Plan: Try it Reviewers: wez, lifeihuang, JoelB, #blessed_reviewers, epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8429
2014-03-06 20:28:46 +01:00
'DiffusionGitFileContentQueryTestCase' => 'PhabricatorTestCase',
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',
Serve Git reads over HTTP Summary: Mostly ripped from D7391. No writes yet. Test Plan: Ran `git clone` against a local over HTTP, got a clone. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7423
2013-10-26 21:10:52 +02:00
'DiffusionGitResponse' => 'AphrontResponse',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'DiffusionHovercardEventListener' => 'PhabricatorEventListener',
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',
Implement a lint count query Summary: Ref T2683. This query is currently unbatched and happens inside a view. Leave it inside the view for now, but separate it and make it batchable. Test Plan: {F34848} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, vrana, aran Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D5252
2014-05-11 00:21:05 +02:00
'DiffusionLintCountQuery' => 'PhabricatorQuery',
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',
Move commit message/metadata field query to a separate class Summary: Ref T4195. I need to query commit metadata to figure out which revision a commit is associated with. Move this out of the MessageParser so the code can be called from the HookEngine. Test Plan: Used `reparse.php` to reparse a variety of SVN, Mercurial and Git commits. Used `var_dump()` to verify sensible fields were returned. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7805
2013-12-20 21:38:44 +01:00
'DiffusionLowLevelCommitFieldsQuery' => 'DiffusionLowLevelQuery',
Provide a low-level SVN commit query, and merge the VCS query types Summary: Ref T4195. Even though we use `svnlook` in the hook itself, I need this query elsewhere, so provide it and merge the classes into one which does the right thing. Test Plan: - Used `reparse.php` to reparse messages for Git, SVN and Mercurial commits, using `var_dump()` to examine the commit refs for sanity. - Used `reparse.php` to reparse changes for an SVN commit. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7800
2013-12-19 20:05:06 +01:00
'DiffusionLowLevelCommitQuery' => 'DiffusionLowLevelQuery',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelGitRefQuery' => 'DiffusionLowLevelQuery',
Clean up `hg --debug branches` calls Summary: Ref T1493. Consolidate these a bit; they might need some more magic once we do `--noupdate` checkouts. Mostly just trying to clean up and centralize this code a bit. Test Plan: Viewed and `bin/repository discover`'d Mercurial repos with and without any branches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7480
2013-11-04 21:15:32 +01:00
'DiffusionLowLevelMercurialBranchesQuery' => 'DiffusionLowLevelQuery',
Modernize Diffusion `commitparentsquery` Summary: Ref T4195. Ref T2783. We have an old-school implementation of this; move it into a LowLevel query and make callers all run through Conduit. I need the LowLevel query for hooks, to implement an "is merge commit" Herald rule. Test Plan: - Ran query via Conduit for SVN, Mercurial, Git. - Parsed a commit which closed a revision, attach/closed worked correctly. - Browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195, T2783 Differential Revision: https://secure.phabricator.com/D7808
2013-12-20 21:39:21 +01:00
'DiffusionLowLevelParentsQuery' => 'DiffusionLowLevelQuery',
Consolidate querying of things which we can use `git for-each-ref` for Summary: Ref T2230. This cleans up D7442, by using `git for-each-ref` everywhere we can, in a basically reasonable way. Test Plan: In bare and non-bare repositories: - Ran discovery with `bin/repository discover`; - listed branches on `/diffusion/X/`; - listed tags on `/diffusion/X/`; - listed tags, branches and refs on `/diffusion/rXnnnn`. Reviewers: btrahan, avivey Reviewed By: avivey CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7447
2013-10-30 21:06:09 +01:00
'DiffusionLowLevelQuery' => 'Phobject',
Merge "expandshortcommitquery" and "stablecommitnamequery" into "resolverefs" Summary: Ref T1493. Diffusion has some garbagey behavior for things we can't resolve. Common cases are: - Looking at a branch that doesn't exist. - Looking at a repository with no branches. - Looking at a commit that doesn't exist. - Looking at an empty repository. In these cases, we generally fatal unhelpfully. I want to untangle this mess. This doesn't help much, but does clean things up a bit. We currently have two separate query paths, "stablecommitname" and "expandshortcommit". These are pretty much doing the same thing -- taking some ref like "master" or "default" or a tag name or part of a commit name, and turning it into a full commit name. Merge them into a single "resolverefs" method. This simplifies the code a fair bit, and gives us better error messages. They still aren't great, but they're like this now: Ref "7498aec194ecf2d333e0e2baddd9d5cdf922d7f1" is ambiguous or does not exist. ...instead of just: ERR-INVALID-COMMIT Test Plan: Looked at Git, Mercurial and Subversion repositories that were empty and non-empty. Looked at branches/heads. Tried to look at invalid commits. Looked at tags. All of this still works, and some behaviors are a bit better than they used to be. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1493 Differential Revision: https://secure.phabricator.com/D7484
2013-11-04 23:13:07 +01:00
'DiffusionLowLevelResolveRefsQuery' => 'DiffusionLowLevelQuery',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionMercurialRawDiffQuery' => 'DiffusionRawDiffQuery',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'DiffusionMercurialRequest' => 'DiffusionRequest',
Allow Phabricator to serve Mercurial repositories over HTTP Summary: Ref T2230. This is easily the worst thing I've had to write in a while. I'll leave some notes inline. Test Plan: Ran `hg clone http://...` on a hosted repo. Ran `hg push` on the same. Changed sync'd both ways. Reviewers: asherkin, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7520
2013-11-07 03:00:42 +01:00
'DiffusionMercurialResponse' => 'AphrontResponse',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'DiffusionMirrorDeleteController' => 'DiffusionController',
'DiffusionMirrorEditController' => 'DiffusionController',
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',
Add a SublimeText-style repository typeahead Summary: Allows you to quickly search for files within a repository. Roughly: - We build a big tree of everything and ship it to the client. - The client implements a bunch of Sublime-ish magic to find paths. Test Plan: {F154007} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, zeeg Differential Revision: https://secure.phabricator.com/D9087
2014-05-13 23:08:21 +02:00
'DiffusionPathTreeController' => 'DiffusionController',
Some owners read workflows.
2011-04-04 04:20:47 +02:00
'DiffusionPathValidateController' => 'DiffusionController',
Provide an "event" page for push logs, which shows details on all events in a given push Summary: Ref T4677. This shows a more detailed view of an entire "git push", "hg push", or "svn commit". This is mostly to give push summary emails a reasonable, stable URI to link to for T4677. Test Plan: - Pushed into SVN, Git and Mercurial. - Viewed partial and imported event records. {F134864} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8616
2014-03-26 15:42:30 +01:00
'DiffusionPushEventViewController' => 'DiffusionPushLogController',
'DiffusionPushLogController' => 'DiffusionController',
Move Push log rendering to SearchEngine Summary: Ref T4986. Move push logs to a View, then have all the stuff that needs to use it use that View. Test Plan: Viewed push logs and transaction detail in Diffusion. Created a panel. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9104
2014-05-13 23:00:24 +02:00
'DiffusionPushLogListController' => 'DiffusionPushLogController',
'DiffusionPushLogListView' => 'AphrontView',
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',
Throw a more tailored exception after failing to resolve a ref Summary: Ref T2683. Throw a more tailored exception to allow callers to distinguish between bad refs (which are expected, if users try to visit garbage branches) and other types of errors. Test Plan: Tried to view branch "alksndfklansdf". Viewed branch "master". Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9094
2014-05-13 22:52:33 +02:00
'DiffusionRefNotFoundException' => 'Exception',
Make the Diffusion UI vaguely usable in some cases.
2011-03-13 01:17:34 +01:00
'DiffusionRepositoryController' => 'DiffusionController',
Sort out application crumbs in new repository edit workflow Summary: Ref T2231. Crumbs in the Diffusion edit workflow are a bit wonky, with stuff like "rP (master)" which isn't very useful and no link back to the main "Edit" page. Make them consistent across all the screens. Test Plan: Loaded a bunch of these screens and saw sane crumbs on all of them. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7407
2013-10-26 00:58:58 +02:00
'DiffusionRepositoryCreateController' => 'DiffusionRepositoryEditController',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'DiffusionRepositoryDefaultController' => 'DiffusionController',
Sort out application crumbs in new repository edit workflow Summary: Ref T2231. Crumbs in the Diffusion edit workflow are a bit wonky, with stuff like "rP (master)" which isn't very useful and no link back to the main "Edit" page. Make them consistent across all the screens. Test Plan: Loaded a bunch of these screens and saw sane crumbs on all of them. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7407
2013-10-26 00:58:58 +02:00
'DiffusionRepositoryEditActionsController' => 'DiffusionRepositoryEditController',
'DiffusionRepositoryEditActivateController' => 'DiffusionRepositoryEditController',
'DiffusionRepositoryEditBasicController' => 'DiffusionRepositoryEditController',
'DiffusionRepositoryEditBranchesController' => 'DiffusionRepositoryEditController',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'DiffusionRepositoryEditController' => 'DiffusionController',
Reject dangerous changes in Git repositories by default Summary: Ref T4189. This adds a per-repository "dangerous changes" flag, which defaults to off. This flag must be enabled to do non-appending branch mutation (delete branches / rewrite history). Test Plan: With flag on and off, performed various safe and dangerous pushes. >>> orbital ~/repos/POEMS $ git push origin :blarp remote: +---------------------------------------------------------------+ remote: | * * * PUSH REJECTED BY EVIL DRAGON BUREAUCRATS * * * | remote: +---------------------------------------------------------------+ remote: \ remote: \ ^ /^ remote: \ / \ // \ remote: \ |\___/| / \// .\ remote: \ /V V \__ / // | \ \ *----* remote: / / \/_/ // | \ \ \ | remote: @___@` \/_ // | \ \ \/\ \ remote: 0/0/| \/_ // | \ \ \ \ remote: 0/0/0/0/| \/// | \ \ | | remote: 0/0/0/0/0/_|_ / ( // | \ _\ | / remote: 0/0/0/0/0/0/`/,_ _ _/ ) ; -. | _ _\.-~ / / remote: ,-} _ *-.|.-~-. .~ ~ remote: \ \__/ `/\ / ~-. _ .-~ / remote: \____(Oo) *. } { / remote: ( (--) .----~-.\ \-` .~ remote: //__\\ \ DENIED! ///.----..< \ _ -~ remote: // \\ ///-._ _ _ _ _ _ _{^ - - - - ~ remote: remote: remote: DANGEROUS CHANGE: The change you're attempting to push deletes the branch 'blarp'. remote: Dangerous change protection is enabled for this repository. remote: Edit the repository configuration before making dangerous changes. remote: To ssh://dweller@localhost/diffusion/POEMS/ ! [remote rejected] blarp (pre-receive hook declined) error: failed to push some refs to 'ssh://dweller@localhost/diffusion/POEMS/' Reviewers: btrahan Reviewed By: btrahan CC: aran, chad, richardvanvelzen Maniphest Tasks: T4189 Differential Revision: https://secure.phabricator.com/D7689
2013-12-03 19:28:39 +01:00
'DiffusionRepositoryEditDangerousController' => 'DiffusionRepositoryEditController',
Move "Delete Repository" stuff to Diffusion Summary: Ref T2231. This just moves the "Delete" dialog from Repositories to Diffusion. This dialog just shows instructions and isn't interesting. Test Plan: {F75093} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7412
2013-10-29 20:26:07 +01:00
'DiffusionRepositoryEditDeleteController' => 'DiffusionRepositoryEditController',
Sort out application crumbs in new repository edit workflow Summary: Ref T2231. Crumbs in the Diffusion edit workflow are a bit wonky, with stuff like "rP (master)" which isn't very useful and no link back to the main "Edit" page. Make them consistent across all the screens. Test Plan: Loaded a bunch of these screens and saw sane crumbs on all of them. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7407
2013-10-26 00:58:58 +02:00
'DiffusionRepositoryEditEncodingController' => 'DiffusionRepositoryEditController',
Add hosting, serving, and push policy options to repository edit Summary: Basically straight from D7391. The differences are basically: - Policy stuff is all application-scope instead of global-scope. - Made a few strings a little nicer. - Deleted a bit of dead code. - Added a big "THIS DOESN'T WORK YET" warning. Test Plan: See screenshots. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7416
2013-10-26 05:13:38 +02:00
'DiffusionRepositoryEditHostingController' => 'DiffusionRepositoryEditController',
Move editing "Local Path" to modern UI/controller/etc Summary: Fixes T1286. Ref T2231. See previous diffs; same as the others but does "Local Path". Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1286, T2231 Differential Revision: https://secure.phabricator.com/D7409
2013-10-29 20:20:26 +01:00
'DiffusionRepositoryEditLocalController' => 'DiffusionRepositoryEditController',
Sort out application crumbs in new repository edit workflow Summary: Ref T2231. Crumbs in the Diffusion edit workflow are a bit wonky, with stuff like "rP (master)" which isn't very useful and no link back to the main "Edit" page. Make them consistent across all the screens. Test Plan: Loaded a bunch of these screens and saw sane crumbs on all of them. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D7407
2013-10-26 00:58:58 +02:00
'DiffusionRepositoryEditMainController' => 'DiffusionRepositoryEditController',
'DiffusionRepositoryEditSubversionController' => 'DiffusionRepositoryEditController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DiffusionRepositoryListController' => 'DiffusionController',
When creating a repository in Diffusion, prompt for "Create" or "Import" first Summary: Ref T2230. This will need some more refinement, but basically it adds a "Create" vs "Import" step before we go through the paged workflow. - If you choose "Create", we skip the remote URI / auth stuff, and then set the "hosted" flag. - If you choose "Import", we do what we do now. Test Plan: Created and imported repos. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7475
2013-11-02 01:39:35 +01:00
'DiffusionRepositoryNewController' => 'DiffusionController',
Remove DiffusionBranchInformation in favor of DiffusionRepositoryRef Summary: Ref T4327. At some point these two very similar classes got introduced. Collapse `DiffusionBranchInformation` into the nearly identical `DiffusionRepositoryRef`, which enjoys slightly more generality and support. Test Plan: Viewed branch overview and detail pages. Ran `repository refs` and `repository discover`. Grepped for removed symbols. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8002
2014-01-18 01:10:56 +01:00
'DiffusionRepositoryRef' => 'Phobject',
Add a Diffusion repository remarkup rule Summary: Currently we markup `rXabcd`, but not `rX` on its own. Mark these up as repository object names. Test Plan: Typed `rPOEMS`, `rPOEMS1`, `rPOEMS139893189`, etc. Reviewers: btrahan, dctrwatson Reviewed By: btrahan CC: aran, poop Differential Revision: https://secure.phabricator.com/D7859
2013-12-31 20:08:08 +01:00
'DiffusionRepositoryRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'DiffusionResolveUserQuery' => 'Phobject',
Serve git writes over SSH Summary: Looks like this is pretty straightforward; same as the reads except mark it as needing PUSH. Test Plan: Ran `git push`, pushed over SSH to a hosted repo. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7425
2013-10-26 23:11:52 +02:00
'DiffusionSSHGitReceivePackWorkflow' => 'DiffusionSSHGitWorkflow',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHGitUploadPackWorkflow' => 'DiffusionSSHGitWorkflow',
'DiffusionSSHGitWorkflow' => 'DiffusionSSHWorkflow',
Enable Mercurial reads and writes over SSH Summary: Ref T2230. This is substantially more complicated than Git, but mostly because Mercurial's protocol is a like 50 ad-hoc extensions cobbled together. Because we must decode protocol frames in order to determine if a request is read or write, 90% of this is implementing a stream parser for the protocol. Mercurial's own parser is simpler, but relies on blocking reads. Since we don't even have methods for blocking reads right now and keeping the whole thing non-blocking is conceptually better, I made the parser nonblocking. It ends up being a lot of stuff. I made an effort to cover it reasonably well with unit tests, and to make sure we fail closed (i.e., reject requests) if there are any parts of the protocol I got wrong. A lot of the complexity is sharable with the HTTP stuff, so it ends up being not-so-bad, just very hard to verify by inspection as clearly correct. Test Plan: - Ran `hg clone` over SSH. - Ran `hg fetch` over SSH. - Ran `hg push` over SSH, to a read-only repo (error) and a read-write repo (success). Reviewers: btrahan, asherkin Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7553
2013-11-11 21:18:27 +01:00
'DiffusionSSHMercurialServeWorkflow' => 'DiffusionSSHMercurialWorkflow',
'DiffusionSSHMercurialWireClientProtocolChannel' => 'PhutilProtocolChannel',
'DiffusionSSHMercurialWireTestCase' => 'PhabricatorTestCase',
'DiffusionSSHMercurialWorkflow' => 'DiffusionSSHWorkflow',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSSHSubversionServeWorkflow' => 'DiffusionSSHSubversionWorkflow',
'DiffusionSSHSubversionWorkflow' => 'DiffusionSSHWorkflow',
Route some VCS connections over SSH Summary: - Add web UI for configuring SSH hosting. - Route git reads (`git-upload-pack` over SSH). Test Plan: >>> orbital ~ $ git clone ssh://127.0.0.1/ Cloning into '127.0.0.1'... Exception: Unrecognized repository path "/". Expected a path like "/diffusion/X/". fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/X/ Cloning into 'X'... Exception: No repository "X" exists! fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/MT/ Cloning into 'MT'... Exception: This repository is not available over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. >>> orbital ~ $ git clone ssh://127.0.0.1/diffusion/P/ Cloning into 'P'... Exception: TODO: Implement serve over SSH. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7421
2013-10-26 19:46:09 +02:00
'DiffusionSSHWorkflow' => 'PhabricatorSSHWorkflow',
Split Diffusion VSC serve code into its own controller Summary: This is starting to get a bit sizable and it turns out Mercurial is sort of a beast, so split the VCS serve stuff into a separate controller. Test Plan: Pushed and pulled an authenticated Git repository. Reviewers: btrahan Reviewed By: btrahan CC: aran, hach-que Differential Revision: https://secure.phabricator.com/D7494
2013-11-07 02:55:46 +01:00
'DiffusionServeController' => 'DiffusionController',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'DiffusionSetPasswordPanel' => 'PhabricatorSettingsPanel',
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',
Support serving SVN repositories over SSH Summary: Ref T2230. The SVN protocol has a sensible protocol format with a good spec here: http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_ra_svn/protocol Particularly, compare this statement to the clown show that is the Mercurial wire protocol: > It is possible to parse an item without knowing its type in advance. WHAT A REASONABLE STATEMENT TO BE ABLE TO MAKE ABOUT A WIRE PROTOCOL Although it makes substantially more sense than Mercurial, it's much heavier-weight than the Git or Mercurial protocols, since it isn't distributed. It's also not possible to figure out if a request is a write request (or even which repository it is against) without proxying some of the protocol frames. Finally, several protocol commands embed repository URLs, and we need to reach into the protocol and translate them. Test Plan: Ran various SVN commands over SSH (`svn log`, `svn up`, `svn commit`, etc). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7556
2013-11-11 21:19:06 +01:00
'DiffusionSubversionWireProtocol' => 'Phobject',
'DiffusionSubversionWireProtocolTestCase' => 'PhabricatorTestCase',
Browse / git improvements.
2011-03-14 06:03:30 +01:00
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
Add "DiffusionRawDiffQuery" Summary: - This is only slightly useful for updating Differential, since DiffQuery (vs RawDiffQuery) already gets you most of what you need. The only thing is that DiffQuery returns the diff for one path only right now(and the SVN version is very "special"). Should be easy to fix in the Git/HG cases at least, though (or maybe just use RawDiffQuery to avoid the SVN mess). - Added a "download raw diff" link. Test Plan: Viewed Diffusion and raw commits for SVN, Mercurial and Git repositories. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2350
2012-05-02 22:43:45 +02:00
'DiffusionSvnRawDiffQuery' => 'DiffusionRawDiffQuery',
Add syntax highlight to diffusion. Summary: use XHPAST parser to parse the file, and generate a table for the code to highlight it. This is part of the task of "Port Diffusion's Browse File view to Phabricator". Test Plan: browse file, try commit version, line number functionality. Reviewed By: epriestley Reviewers: epriestley CC: epriestley Differential Revision: 83
2011-03-23 03:34:47 +01:00
'DiffusionSvnRequest' => 'DiffusionRequest',
Add a simple symbol lookup interface for cross-references Summary: This will get fancier, but here's a basic interface for doing symbol lookups. Still all pretty tentative. Test Plan: Looked up various things, got some sensible results. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, tuomaspelkonen Differential Revision: 900
2011-09-05 19:43:24 +02:00
'DiffusionSymbolController' => 'DiffusionController',
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',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DivinerAtomListController' => 'DivinerController',
Use ApplicationSearch in Diviner Summary: Ref T988. Ref T2625. Rough cut of ApplicationSearch in Diviner, for detailed Atom queries. This isn't useful yet, and isn't linked in the UI. Test Plan: {F44836} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988, T2625 Differential Revision: https://secure.phabricator.com/D6094
2013-05-31 19:52:25 +02:00
'DivinerAtomQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'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',
Diviner Book Index styles Summary: Slightly more readable, less space than current index. LMK if you hate it though. Test Plan: Look at user and dev book indexes. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6932
2013-09-10 18:39:50 +02:00
'DivinerBookItemView' => 'AphrontTagView',
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',
Diviner: improve links, book index, and atom view Summary: Ref T988. Minor improvements to diviner: link stuff to a valid endpoint which actually works; fix group names on the book index; improve the topics index for atom views. Test Plan: Clicked links in an article, viewed book index, viewed an article with long headers. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6598
2013-07-28 22:07:30 +02:00
'DivinerFindController' => 'DivinerController',
Port Diviner Core to Phabricator Summary: This implements most/all of the difficult parts of Diviner on top of Phabricator instead of as standalone components. See T988. In particular, here are the things I want to fix: **Performance** The Diviner parser works in two stages. The first stage breaks source files into "Atoms". The second stage renders atoms into a display format (e.g., HTML). Diviner currently has a good caching story on the first step of the pipeline, but zero caching in the second step. This means it's very slow, even for a fairly small project like Phabricator. We must re-render every piece of documentation every time, instead of only changed documentation. Most of this diff concerns itself with addressing this problem. There's a fairly large explanatory comment about it, but the trickiest part is that when an atom changes, other atoms (defined in other places) may also change -- for example, if `class B extends A`, editing A should dirty B, even if B is in an entirely different file. We perform analysis in two stages to propagate these changes: first detecting direct changes, then detecting indirect changes. This isn't completely implemented -- we need to propagate 'extends' through more levels -- but I believe it's structurally correct and good enough until we actually document classes. **Inheritance** Diviner currently has a very weak story on inheritance. I want to inherit a lot more metas/docs. If an interface documents a method, we should just pull that documentation in to every implementation by default (implementations can still override it if they want). It can be shown in grey or something, but it should be desirable and correct to omit documentation of a method implementation when you are implementing a parent. Similarly, I want to pull in inherited methods and @tasks and such. This diff sets up for that, by formalizing "extends" relationships between atoms. **Overspecialization** Diviner currently specializes atoms (FileAtom, FunctionAtom, ClassAtom, etc.). This is pretty much not useful, because Atomizers (which produce the atoms) need to be highly specialized, and Renderers/Publishers (which consume the atoms) also need to be highly specialized. Nothing interesting actually lives in the atom specializations, and we don't benefit from having them -- it just costs us generality in storage/caches for them. In the new code, I've used a single Atom class to represent any type of atom. **URIs** We have fairly hideous URIs right now, which are very cumbersome For in-app doc links, I want to provide nice URIs ("/h/notfications" or similar) which are stable redirects, and probably add remarkup for it: !{notifications} or similar. This diff isn't related to that since it's too premature. **Search** Once we have a database generation target, we can index the documentation. **Design** Chad has some nice mocks. Test Plan: Ran `bin/diviner generate`, `bin/diviner generate --clean`. Saw appropriate graph propagation after edits. This diff doesn't do anything very useful yet. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4340
2013-01-07 23:04:23 +01:00
'DivinerGenerateWorkflow' => 'DivinerWorkflow',
Add another pattern to quoted email body stripping Summary: Ref T3217. @hlau has an email client which quotes text with: ________________________________________ From: ... Add a regular expression to correctly detect this as quoted body text. Test Plan: Add unit test; executed unit test. Reviewers: btrahan, chad Reviewed By: chad CC: hlau, aran Maniphest Tasks: T3217 Differential Revision: https://secure.phabricator.com/D5986
2013-05-21 00:52:54 +02:00
'DivinerLiveAtom' => 'DivinerDAO',
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
),
Give Diviner a non-legacy root controller Summary: Ref T988. Instead of hard-coding the application landing page, make the Diviner root show books if any have been generated. Otherwise, show a helpful message about how to generate documentation locally. Test Plan: {F122723} {F122724} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D8416
2014-03-05 22:07:50 +01:00
'DivinerMainController' => 'DivinerController',
Use application PHIDs for ATOM Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6597
2013-07-30 15:49:13 +02:00
'DivinerPHIDTypeAtom' => 'PhabricatorPHIDType',
Use application PHIDs for Diviner Books Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6596
2013-07-30 15:47:07 +02:00
'DivinerPHIDTypeBook' => 'PhabricatorPHIDType',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerPHPAtomizer' => 'DivinerAtomizer',
'DivinerParameterTableView' => 'AphrontTagView',
Add a publish cache for the Diviner static publisher Summary: Keep track of what we've written to disk, and regenerate only new documents. Test Plan: Changed a small number of files, saw that number of files get regenerated. Ran with "--clean" and saw everything regenerate. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4897
2013-02-18 00:40:00 +01:00
'DivinerPublishCache' => 'DivinerDiskCache',
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',
Generate PHP function documentation in Diviner Summary: Ref T988. Various improvements: - Generate function documentation, mostly correctly. - Raise some warnings about bad documentation. - Allow `.book` files to exclude paths from generation. - Add a book for technical docs. - Exclude "ghosts" from common queries (atoms which used to exist, but no longer do, but which we want to keep the PHIDs around for in case they come back later). This is a bit rough still, but puts us much closer to being able to get rid of the old Diviner. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D6812
2013-08-27 12:14:00 +02:00
'DivinerReturnTableView' => 'AphrontTagView',
More Diviner style updates Summary: This adds a number of new styles for Diviner documentation. Not sure I've covered all the bases or wrote this in the most efficient manner, but passing it along now for early review before tightening everything up. Test Plan: Review various class pages. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6888
2013-09-05 21:29:07 +02:00
'DivinerSectionView' => 'AphrontTagView',
Move Diviner further toward usability Summary: - Complete the "project" -> "book" stuff. This is cleaner conceptually and keeps us from having yet another meaning for the word "project". - Normalize symbols during atomization. This simplifies publishing a great deal, and allows static documentation to link to dynamic documentation and vice versa, because the canonical names of symbols are agreed upon (we can tweak the actual algorithm). - Give articles a specifiable name distinct from the title, and default to something like "support" instead of "Get Help! Get Support!" so URIs end up more readable (not "Get_Help!_Get_Support!"). - Have the atomizers set book information on atoms. - Implement very basic publishers. Publishers are basically glue code between the atomization process and the rendering process -- the two we'll have initially are "static" (publish to files on disk) and "phabricator" (or similar -- publish into the database). - Handle duplicate symbol definitions in the atomize and publish pipelines. This fixes the issue where a project defines two functions named "idx()" and we currently tell them not to do that and break. Realistically, this is common in the real world and we should just roll our eyes and do the legwork to generate documentation as best we can. - Particularly, dirty all atoms with the same name as a dirty atom (e.g., if 'function f()' is updated, regnerate the documentation for all functions named f() in the book). - When publishing, we publish these at "function/f/@1", "function/f/@2". The base page will offer to disambiguate ("There are 8 functions named 'f' in this codebase, which one do you want?"). - Implement a very very basic renderer. This generates the actual HTML (or text, or XML, or whatever else) for the documentation, which the publisher dumps onto disk or into a database or whatever. - The atomize workflow actually needs to depend on books, at least sort of, so make it load config and use it properly. - Propagate multilevel dirties through the graph. If "C extends B" and "B extends A", we should regenerate C when A changes. Prior to this diff, we would regnerate B only. Test Plan: Generated some documentation. Named two articles "feedback", generated docs, saw "article/feedback/@1/" and "article/feedback/@2/" created. Reviewers: btrahan, vrana, chad Reviewed By: chad CC: aran Maniphest Tasks: T988 Differential Revision: https://secure.phabricator.com/D4896
2013-02-18 00:39:36 +01:00
'DivinerStaticPublisher' => 'DivinerPublisher',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'DivinerWorkflow' => 'PhabricatorManagementWorkflow',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperBridge' => 'Phobject',
'DoorkeeperBridgeAsana' => 'DoorkeeperBridge',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperBridgeJIRA' => 'DoorkeeperBridge',
Fix JIRA issue URI selection for JIRA installs which are not on the domain root Summary: Fixes T4859. See that for details. Test Plan: - Verified things still work on my local (domain root) install. - Added some unit tests. - Did not verify a non-root install since I don't have one handy, hopefully @salehe can help. Reviewers: btrahan Reviewed By: btrahan Subscribers: salehe, epriestley Maniphest Tasks: T4859 Differential Revision: https://secure.phabricator.com/D8836
2014-05-18 14:45:21 +02:00
'DoorkeeperBridgeJIRATestCase' => 'PhabricatorTestCase',
Add DoorkeeperExternalObject Summary: Ref T2852. This table holds data about external objects and allows us to write edges to them. Objects are identified with an `<applicationType, applicationDomain, objectType, objectID>` tuple. For example, Asana tasks will be, e.g., `<asana, asana.com, asana:task, 93829279873>` or similar. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6271
2013-06-25 00:54:36 +02:00
'DoorkeeperDAO' => 'PhabricatorLiskDAO',
'DoorkeeperExternalObject' =>
array(
0 => 'DoorkeeperDAO',
1 => 'PhabricatorPolicyInterface',
),
Add DoorkeeperExternalObjectQuery, expose more ref/import APIs Summary: Ref T2852. - Broadly, we support "I have a Ref, I need a PHID" well but not "I have a PHID, I need a Ref". - Add DoorkeeperExternalObjectQuery, and use it to query ExternalObjects. - Allow external objects to be imported by their internal PHIDs. Basically, if we have an edge pointing at an ExternalObject, we can say "load all the data about this" from just the PHID and have it hit all the same code. - Allow construction of Refs from ExternalObjects. This makes the "I have a PHID, I need a Ref" easier. Test Plan: - Verified Asana links still enrich properly at display time. - Used in future revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6294
2013-06-26 01:30:44 +02:00
'DoorkeeperExternalObjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Refactor shared code between JIRA + Asana publishers into a base class Summary: Ref T3687. See some discussion in D6892. The JIRA doorkeeper publisher shares a reasonable amount of code with the Asana publisher. Remedy this: - Create `DoorkeeperFeedWorker`, where shared functionality lives (mostly related to building story context objects). - Push responsibility for enabling/disabling a worker into this new layer, via `isEnabled()`. This allows `FeedPublisherWorker` to dynamically find and schedule doorkeeper publishers, so third parties can add additional doorkeeper publishers. - Some general cleanup/documentation. Test Plan: Used `bin/feed republish` to republish stories about objects with JIRA and Asana links. Verified that doorkeeper publishers activated properly, made calls, and published events into the remote systems. Reviewers: btrahan, akopanev22 Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6906
2013-09-11 00:22:01 +02:00
'DoorkeeperFeedWorker' => 'FeedPushWorker',
'DoorkeeperFeedWorkerAsana' => 'DoorkeeperFeedWorker',
'DoorkeeperFeedWorkerJIRA' => 'DoorkeeperFeedWorker',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperImportEngine' => 'Phobject',
Make "JIRA Issues" field work better with noncredentialed accounts Summary: Currently, users get an error when making any changes to this field if they don't have a linked JIRA account. Instead: - We should only raise an error if they're trying to //add// issues, and only on the new issues. It's always fine to remove issues, and existing issues the author can't see are also fine. - When we can't add things because there's no account (vs because there's a permissions error or they don't exist), raise a more tailored exception. Test Plan: - As JIRA and non-JIRA users, made various edits to this field. - Got appropriate exceptions, including better tailoring. Reviewers: btrahan Reviewed By: btrahan Subscribers: mbishopim3, epriestley Differential Revision: https://secure.phabricator.com/D8676
2014-04-02 21:03:59 +02:00
'DoorkeeperMissingLinkException' => 'Exception',
Add DoorkeeperObjectRef, DoorkeeperBridge, DoorkeeperBridgeAsana Summary: - `DoorkeeperObjectRef` is a convenience object to keep track of `<applicationType, applicationDomain, objectType, objectID>` tuples. - `DoorkeeperBridge` provides pull/push between Phabricator and external systems. - `DoorkeeperBridgeAsana` is a bridge to Asana. Test Plan: Ran this snippet and got a task from Asana: {P871} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6273
2013-06-25 00:54:54 +02:00
'DoorkeeperObjectRef' => 'Phobject',
Add JIRA doorkeeper and remarkup support Summary: Ref T3687. Adds a Doorkeeper bridge for JIRA issues, plus remarkup support. In particular: - The Asana and JIRA remarkup rules shared most of their implementation, so I refactored what I could into a base class. - Actual bridge implementation is straightforward and similar to Asana, although probably not similar enough to really justify refactoring. Test Plan: - When logged in as a JIRA-connected user, pasted a JIRA issue link and saw it enriched at rendering time. - Logged in and out with JIRA. - Tested an Asana link, too (seems I haven't broken anything). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6878
2013-09-04 02:27:38 +02:00
'DoorkeeperRemarkupRule' => 'PhutilRemarkupRule',
'DoorkeeperRemarkupRuleAsana' => 'DoorkeeperRemarkupRule',
'DoorkeeperRemarkupRuleJIRA' => 'DoorkeeperRemarkupRule',
Render linked JIRA issues with a Doorkeeper tag Summary: Fixes T3687. Instead of rendering "JIRA Issues" in Differential using plain links, render them using Doorkeeper tags so they get the nice "enhance with object name" effect. Test Plan: {F84886} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D7648
2013-11-25 23:54:35 +01:00
'DoorkeeperTagView' => 'AphrontView',
Add remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'DoorkeeperTagsController' => 'PhabricatorController',
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',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockBlueprint' =>
array(
0 => 'DrydockDAO',
1 => 'PhabricatorPolicyInterface',
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintController' => 'DrydockController',
'DrydockBlueprintCreateController' => 'DrydockBlueprintController',
'DrydockBlueprintEditController' => 'DrydockBlueprintController',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintEditor' => 'PhabricatorApplicationTransactionEditor',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'DrydockBlueprintListController' => 'DrydockBlueprintController',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockBlueprintQuery' => 'DrydockQuery',
Use ApplicationSearch for Drydock Blueprints Summary: Ref T2015. This turns the side nav into a bigger mess for now, but uses ApplicationSearch for blueprints. Test Plan: Queried blueprints in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7829
2013-12-26 21:30:04 +01:00
'DrydockBlueprintSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add transactions to Drydock blueprint editing Summary: Ref T2015. Fixes TODO. Test Plan: {F100338} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7922
2014-01-09 21:19:54 +01:00
'DrydockBlueprintTransaction' => 'PhabricatorApplicationTransaction',
'DrydockBlueprintTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockBlueprintViewController' => 'DrydockBlueprintController',
Add Drydock default edit/view policies and a "Create Blueprint" policy Summary: Ref T2015. Allow configuration of default edit/view policies for blueprints. Add create policy. Remove administrative exception in policies. Test Plan: Configured these settings and created (or, with a restrictive create setting, tried to create) blueprints. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7921
2014-01-09 21:19:45 +01:00
'DrydockCapabilityCreateBlueprints' => 'PhabricatorPolicyCapability',
'DrydockCapabilityDefaultEdit' => 'PhabricatorPolicyCapability',
'DrydockCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockCommandInterface' => 'DrydockInterface',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockConsoleController' => 'DrydockController',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockController' => 'PhabricatorController',
'DrydockDAO' => 'PhabricatorLiskDAO',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockFilesystemInterface' => 'DrydockInterface',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
'DrydockLease' =>
array(
0 => 'DrydockDAO',
1 => 'PhabricatorPolicyInterface',
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseController' => 'DrydockController',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLeaseListController' => 'DrydockLeaseController',
'DrydockLeaseListView' => 'AphrontView',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockLeaseQuery' => 'DrydockQuery',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseReleaseController' => 'DrydockLeaseController',
Use ApplicationSearch to manage DrydockLeases Summary: Ref T2015. Applies ApplicationSearch to DrydockLease. This makes the left nav in Drydock a little funky. It will probably get worse for a bit before it gets better, since I want to bring everything to ApplicationSearch and then sort out the details. Test Plan: Queried leases in Drydock. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7827
2013-12-26 19:42:00 +01:00
'DrydockLeaseSearchEngine' => 'PhabricatorApplicationSearchEngine',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockLeaseStatus' => 'DrydockConstants',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLeaseViewController' => 'DrydockLeaseController',
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',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockLocalHostBlueprintImplementation' => 'DrydockBlueprintImplementation',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLog' =>
array(
0 => 'DrydockDAO',
1 => 'PhabricatorPolicyInterface',
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockLogController' => 'DrydockController',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockLogListController' => 'DrydockLogController',
'DrydockLogListView' => 'AphrontView',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockLogQuery' => 'DrydockQuery',
Use ApplicationSearch for DrydockLog Summary: Ref T2015. Move logs over to ApplicationSearch. Test Plan: Browsed logs in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7832
2013-12-26 21:30:29 +01:00
'DrydockLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add 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',
Drydock blueprint for preallocated remote hosts Summary: This adds a Drydock blueprint for preallocated, remote hosts. This will be used by the Harbormaster interface to allow users to specify remote hosts that builds can be run on. This adds a `canAllocateResource` method to Drydock blueprints; it is used to detect whether a blueprint can allocate a resource for the given type and attributes. Test Plan: Ran: ``` bin/drydock lease --type host --attributes remote=true,preallocated=true,host=192.168.56.101,port=22,user=james,keyfile=,path=C:\\Build\\,platform=windows ``` and saw the "C:\Build\<id>" folder appear on the remote Windows machine. Viewed the lease and resource in Drydock as well. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T4111 Differential Revision: https://secure.phabricator.com/D7593
2013-11-22 23:34:09 +01:00
'DrydockManagementCreateResourceWorkflow' => '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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'DrydockManagementWorkflow' => 'PhabricatorManagementWorkflow',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockPHIDTypeBlueprint' => 'PhabricatorPHIDType',
Make Drydock Lease and Resource PHIDs use newer PHID infrastructure Summary: Ref T2015. These never got updated to the new stuff, move them out of the old `Constants` class and let them load handles, etc. Also some half-cleanup of some Blueprint/BlueprintImplementation stuff. Test Plan: Used `phid.query` to query a Resource, Lease, and Blueprint. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7828
2013-12-26 21:29:58 +01:00
'DrydockPHIDTypeLease' => 'PhabricatorPHIDType',
'DrydockPHIDTypeResource' => 'PhabricatorPHIDType',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockPreallocatedHostBlueprintImplementation' => 'DrydockBlueprintImplementation',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Update a few things in Drydock for policies Summary: DrydockResource has been updated to be policy-aware (although there are no policy columns). Test Plan: Clicked around in Drydock, viewed resources and leases, everything still seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3605, T4111 Differential Revision: https://secure.phabricator.com/D7595
2013-11-27 22:32:51 +01:00
'DrydockResource' =>
array(
0 => 'DrydockDAO',
1 => 'PhabricatorPolicyInterface',
),
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceCloseController' => 'DrydockResourceController',
'DrydockResourceController' => 'DrydockController',
Move Drydock object list rendering to SearchEngine Summary: Ref T4986. Allows the Drydock search engines to render as panels. Test Plan: Viewed affected interfaces in Drydock. Created panels from each engine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9103
2014-05-13 21:14:33 +02:00
'DrydockResourceListController' => 'DrydockResourceController',
'DrydockResourceListView' => 'AphrontView',
Introduce DrydockQuery to slightly reduce code duplication Summary: Ref T2015. All the Drydock query classes share the application method; move it into a shared base class to slightly shrink the codebase. Test Plan: Browsed query UIs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7837
2013-12-27 22:15:30 +01:00
'DrydockResourceQuery' => 'DrydockQuery',
Use ApplicationSearch for Drydock Resources Summary: Ref T2015. Bring ApplicationSearch to Resources, too. Test Plan: Browsed/queried resources in UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7830
2013-12-26 21:30:10 +01:00
'DrydockResourceSearchEngine' => 'PhabricatorApplicationSearchEngine',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockResourceStatus' => 'DrydockConstants',
Provide a Drydock "Console" controller Summary: Ref T2015. After introducing ApplicationSearch, the left nav turned into a soupy mess. Split the major sections into four separate areas, and unify them with a simple console. This also reverts all the prefix stuff, since the results were awful and I don't anticipate it ever being the best solution to any UX problem. Test Plan: Browsed blueprints, resources, leases and logs. Here's the new console: {F93279} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7833
2013-12-26 21:30:36 +01:00
'DrydockResourceViewController' => 'DrydockResourceController',
Implement "Upload Artifact" build step Summary: This implements a build step for uploading an artifact from a build machine to Phabricator. It uses SFTP so that it will work on both UNIX and Windows build machines. Test Plan: Ran an "Upload Artifact" build against a Windows machine (with FreeSSHD installed). The artifact uploaded to Phabricator, appeared on the build view and the file contents could be viewed from Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7582
2013-12-06 04:11:05 +01:00
'DrydockSFTPFilesystemInterface' => 'DrydockFilesystemInterface',
Drydock Rough Cut Summary: Rough cut of Drydock. This is very basic and doesn't do much of use yet (it //does// allocate EC2 machines as host resources and expose interfaces to them), but I think the overall structure is more or less reasonable. == Interfaces Vision: Applications interact with Drydock resources through DrydockInterfaces, like **command**, **filesystem** and **httpd** interfaces. Each interface allows applications to perform some kind of operation on the resource, like executing commands, reading/writing files, or configuring a web server. Interfaces have a concrete, specific API: // Filesystem Interface $fs = $lease->getInterface('filesystem'); // Constants, some day? $fs->writeFile('index.html', 'hello world!'); // Command Interface $cmd = $lease->getInterface('command'); echo $cmd->execx('uptime'); // HTTPD Interface $httpd = $lease->getInterface('httpd'); $httpd->restart(); Interfaces are mostly just stock, although installs might add new interfaces if they expose different ways to interact with resources (for instance, a resource might want to expose a new 'MongoDB' interface or whatever). Currently: We have like part of a command interface. == Leases Vision: Leases keep track of which resources are in use, and what they're being used for. They allow us to know when we need to allocate more resources (too many sandcastles on the existing hosts, e.g.) and when we can release resources (because they are no longer being used). They also give applications something to hold while resources are being allocated. // EXAMPLE: How this should work some day. $allocator = new DrydockAllocator(); $allocator->setResourceType('sandcastle'); $allocator->setAttributes( array( 'diffID' => $diff->getID(), )); $lease = $allocator->allocate(); $diff->setSandcastleLeaseID($lease->getID()); // ... if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) { $sandcastle_link = $lease->getInterface('httpd')->getURI('/'); } else { $sandcastle_link = 'Still building your sandcastle...'; } echo "Sandcastle for this diff: ".$sandcastle_link; // EXAMPLE: How this actually works now. $allocator = new DrydockAllocator(); $allocator->setResourceType('host'); // NOTE: Allocation is currently synchronous but will be task-driven soon. $lease = $allocator->allocate(); Leases are completely stock, installs will not define new lease types. Currently: Leases exist and work but are very very basic. == Resources Vision: Resources represent some actual thing we've put somewhere, whether it's a host, a block of storage, a webroot, or whatever else. Applications interact through resources by acquiring leases to them, and then getting interfaces through these leases. The lease acquisition process has a side effect of allocating new resources if a lease can't be acquired on existing resources (e.g., the application wants storage but all storage resources are full) and things are configured to autoscale. Resources may themselves acquire leases in order to allocate. For instance, a storage resource might first acquire a lease to a host resource. A 'test scaffold' resource might lease a storage resource and a mysql resource. Not all resources are auto-allocate: the entry-level version of Drydock is that you manually allocate a couple boxes and configure them through the web console. Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the host pool itself does not autoscale. Resources are completely stock, they are abstract shells representing any arbitrary thing. Currently: Resource exist ('host' only) but are very very basic. == Blueprints Vision: Blueprints contain instructions for building interfaces to, (possibly) allocating, updating, managing, and destroying a specific type of resource in a specific location. One way to think of them is that they are scripts for creating and deleting resources. For example, the LocalHost, RemoteHost and EC2Host blueprints can all manage 'host' resources. Eventually, we will support more types of resources (storage, webroot, sandcastle, test scaffold, phacility deployment) and more providers for resource types, some of which will be in the Phabricator mainline and some of which will be custom. Blueprints are very custom and specific to application types, so installs will define new blueprints if they are making significant use of Drydock. Currently: They exist but have few capabilities. The stock blueprints do nearly nothing useful. There is a technically functional blueprint for host allocation in EC2. == Allocator This is just the actual code to execute the lease acquisition process. Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2, acquired a lease on it, interfaced with it, and then released the lease. Ran it again, got a fresh lease on the existing resource. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
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',
Restructure Drydock so that blueprints are instances in the DB Summary: //(this diff used to be about applying policies to blueprints)// This restructures Drydock so that blueprints are instances in the DB, with an associated implementation class. Thus resources now have a `blueprintPHID` instead of `blueprintClass` and DrydockBlueprint becomes a DAO. The old DrydockBlueprint is renamed to DrydockBlueprintImplementation, and the DrydockBlueprint DAO has a `blueprintClass` column on it. This now just implements CAN_VIEW and CAN_EDIT policies for blueprints, although they are probably not enforced in all of the places they could be. Test Plan: Used the `create-resource` and `lease` commands. Closed resources and leases in the UI. Clicked around the new and old lists to make sure everything is still working. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T2015 Differential Revision: https://secure.phabricator.com/D7638
2013-12-03 01:09:07 +01:00
'DrydockWorkingCopyBlueprintImplementation' => 'DrydockBlueprintImplementation',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'FeedPublisherHTTPWorker' => 'FeedPushWorker',
'FeedPublisherWorker' => 'FeedPushWorker',
'FeedPushWorker' => 'PhabricatorWorker',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'FileCreateMailReceiver' => 'PhabricatorMailReceiver',
'FileMailReceiver' => 'PhabricatorObjectMailReceiver',
'FileReplyHandler' => 'PhabricatorMailReplyHandler',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuild' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
),
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildActionController' => 'HarbormasterController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildArtifact' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
),
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
'HarbormasterBuildArtifactQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterBuildCommand' => 'HarbormasterDAO',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildEngine' => 'Phobject',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildItem' => 'HarbormasterDAO',
'HarbormasterBuildItemQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildLog' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
),
'HarbormasterBuildLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow external systems to send messages to build targets Summary: Ref T1049. Allows external systems to send a message to a build target. The primary intended use case is: - You make an HTTP request to Jenkins. - The build goes into a "waiting" state. - Later, Jenkins calls `harbormaster.sendmessage` to report that the target passed or failed. - The build continues as appropriate. This is deceptively complicated because: - There are a lot of race concerns. We might get a message back from an external system before it even responds to the request we made. We want to make sure we process these messages no matter when we receive them. - These messages need to be sent to a build target (vs a build or buildable) because we'll get into trouble with parallelization later on otherwise (Jenkins is told to do 3 builds; we can't tell which ones failed or what overall state is unless the message are sent to targets). - I initially thought about implementing this as a separate "Wait for a response from an external system" build step. This gets a lot more complicated for users once we do parallelization, though. Particularly, in the case where you've told Jenkins to do 3 builds, the three "wait" steps need to know which target they're waiting for (and jenkins needs to know some unique identifier for each target). So this pretty much boils down to a more complicated, more error-prone version of using target PHIDs. This makes the already-muddy Build UI a bit worse, but it needs a general clarity pass anyway (it's showing way too much uninteresting data, and should show a better summary of results instead). Test Plan: - This doesn't really do anything interesting yet. - Used Conduit to send messages to build plans. - Viewed the messages on the build screen. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8604
2014-03-26 00:11:28 +01:00
'HarbormasterBuildMessage' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
),
'HarbormasterBuildMessageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildPlan' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
2 => 'PhabricatorSubscribableInterface',
),
'HarbormasterBuildPlanEditor' => 'PhabricatorApplicationTransactionEditor',
'HarbormasterBuildPlanQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'HarbormasterBuildPlanSearchEngine' => 'PhabricatorApplicationSearchEngine',
'HarbormasterBuildPlanTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildPlanTransactionComment' => 'PhabricatorApplicationTransactionComment',
'HarbormasterBuildPlanTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'HarbormasterBuildQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add build step implementation infrastructure and sleep build step. Summary: Depends on D7498. This implements support for a "build step implementation". Build steps have an associated class name (which makes the class in PHP) and a details field, which is serialized JSON (same as PhabricatorRepository). This also implements a SleepBuildStepImplementation which just pauses the build for a specified period of seconds. Test Plan: Inserted a build step with `insert into harbormaster_buildstep (phid, buildPlanPHID, className, details, dateCreated, dateModified) values ('', 'PHID-HMCP-zkh5w6czfbfpk2gxwdeo', 'SleepBuildStepImplementation', '{"seconds":5}', NOW(), NOW());` (adjusting the build plan PHID as appropriate). Started the daemon and applied the build plan to a buildable, and saw the daemon take a 5 second delay after creating `SleepBuildStepImplementation`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7499
2013-11-05 22:34:14 +01:00
'HarbormasterBuildStep' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
2 => 'PhabricatorCustomFieldInterface',
Add build step implementation infrastructure and sleep build step. Summary: Depends on D7498. This implements support for a "build step implementation". Build steps have an associated class name (which makes the class in PHP) and a details field, which is serialized JSON (same as PhabricatorRepository). This also implements a SleepBuildStepImplementation which just pauses the build for a specified period of seconds. Test Plan: Inserted a build step with `insert into harbormaster_buildstep (phid, buildPlanPHID, className, details, dateCreated, dateModified) values ('', 'PHID-HMCP-zkh5w6czfbfpk2gxwdeo', 'SleepBuildStepImplementation', '{"seconds":5}', NOW(), NOW());` (adjusting the build plan PHID as appropriate). Started the daemon and applied the build plan to a buildable, and saw the daemon take a 5 second delay after creating `SleepBuildStepImplementation`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7499
2013-11-05 22:34:14 +01:00
),
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepCoreCustomField' =>
array(
0 => 'HarbormasterBuildStepCustomField',
1 => 'PhabricatorStandardCustomFieldInterface',
),
'HarbormasterBuildStepCustomField' => 'PhabricatorCustomField',
'HarbormasterBuildStepEditor' => 'PhabricatorApplicationTransactionEditor',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildStepQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationTransactions and CustomField to implement build steps Summary: Ref T1049. Fixes T4602. Moves all the funky field stuff to CustomField. Uses ApplicationTransactions to apply and record edits. This makes "artifact" fields a little less nice (but still perfectly usable). With D8599, I think they're reasonable overall. We can improve this in the future. All other field types are better (e.g., fixes weird bugs with "bool", fixes lots of weird behavior around required fields), and this gives us access to many new field types. Test Plan: Made a bunch of step edits. Here's an example: {F133694} Note that: - "Required" fields work correctly. - the transaction record is shown at the bottom of the page. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4602, T1049 Differential Revision: https://secure.phabricator.com/D8600
2014-03-26 00:08:40 +01:00
'HarbormasterBuildStepTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildStepTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Introduce HarbormasterBuildTarget to snapshot build steps through a build Summary: This implements build targets as outlined in D7582. Build targets represent an instance of a build step particular to the build. Logs and artifacts have been adjusted to attach to build targets instead of build / build step pairs. Test Plan: Ran builds and clicked around the interface. Everything seemed to work. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4111, T1049 Differential Revision: https://secure.phabricator.com/D7703
2013-12-05 02:01:12 +01:00
'HarbormasterBuildTarget' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
),
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildTargetQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'HarbormasterBuildTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterBuildViewController' => 'HarbormasterController',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterBuildWorker' => 'HarbormasterWorker',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildable' =>
array(
0 => 'HarbormasterDAO',
1 => 'PhabricatorPolicyInterface',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
2 => 'HarbormasterBuildableInterface',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
),
Allow entire buildables to restart/stop/resume Summary: Ref T1049. Creates convenience actions at the Buildable level to stop, resume, or restart all builds. Test Plan: - Stopped all builds. - Resumed all builds. - Restarted all builds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7899
2014-01-06 23:12:15 +01:00
'HarbormasterBuildableActionController' => 'HarbormasterController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HarbormasterBuildableListController' => 'HarbormasterController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'HarbormasterBuildableSearchEngine' => 'PhabricatorApplicationSearchEngine',
Show command transactions in Harbormaster builds Summary: Create transaction, editor, etc, and move command generation over to editor. Show in a timeline in the buildable page. Also prevent Engine from creating an empty transaction when build starts (Fixes T4885). Fixes T4886. Test Plan: Restart builds and buildables, look at timeline. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4885, T4886 Differential Revision: https://secure.phabricator.com/D9110
2014-05-15 16:02:30 +02:00
'HarbormasterBuildableTransaction' => 'PhabricatorApplicationTransaction',
'HarbormasterBuildableTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'HarbormasterBuildableTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterBuildableViewController' => 'HarbormasterController',
'HarbormasterCapabilityManagePlans' => 'PhabricatorPolicyCapability',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterCommandBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterController' => 'PhabricatorController',
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',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterHTTPRequestBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterLeaseHostBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
'HarbormasterManagementBuildWorkflow' => 'HarbormasterManagementWorkflow',
Give Buildables a status, populate it, and return it over Conduit Summary: Ref T4809. Currently, buildables have a status field but nothing populates it. Populate it: - When builds change state, update the Buildable state. - Use the new Buildable state on the web UI. - Return the new Buildable state from Conduit. To make it easier to debug/test this: - Provide `bin/harbormaster update Bxxx ...` to force foreground update of a Buildable. Test Plan: - Used `bin/harbormaster update Bxxx --force --trace` to update buildables. - Looked at buidlable list, saw statuses reported properly. - Used Conduit to read statuses. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4809 Differential Revision: https://secure.phabricator.com/D8799
2014-04-18 01:01:16 +02:00
'HarbormasterManagementUpdateWorkflow' => 'HarbormasterManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'HarbormasterManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPHIDTypeBuild' => 'PhabricatorPHIDType',
'HarbormasterPHIDTypeBuildItem' => 'PhabricatorPHIDType',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'HarbormasterPHIDTypeBuildLog' => 'PhabricatorPHIDType',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPHIDTypeBuildPlan' => 'PhabricatorPHIDType',
'HarbormasterPHIDTypeBuildStep' => 'PhabricatorPHIDType',
'HarbormasterPHIDTypeBuildTarget' => 'PhabricatorPHIDType',
'HarbormasterPHIDTypeBuildable' => 'PhabricatorPHIDType',
Replace "Cancel Build" with "Stop", "Resume" and "Restart" Summary: Ref T1049. Currently you can cancel a build, but now that we're tracking a lot more state we can stop, resume, and restart builds. When the user issues a command against a build, I'm writing it into an auxiliary queue (`HarbormasterBuildCommand`) and then reading them out in the worker. This is mostly to avoid race messes where we try to `save()` the object in multiple places: basically, the BuildEngine is the //only// thing that writes to Build objects, and it holds a lock while it does it. Test Plan: - Created a plan which runs "sleep 2" a bunch of times in a row. - Stopped, resumed, and restarted it. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7892
2014-01-06 21:32:20 +01:00
'HarbormasterPlanController' => 'HarbormasterController',
Allow Harbormaster build plans to be disabled Summary: Fixes T4187. Ref T1049. Allows build plans to be enabled or disabled. Test Plan: Enabled and disabled build plans. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4187, T1049 Differential Revision: https://secure.phabricator.com/D7822
2013-12-26 19:40:22 +01:00
'HarbormasterPlanDisableController' => 'HarbormasterPlanController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanEditController' => 'HarbormasterPlanController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HarbormasterPlanListController' => 'HarbormasterPlanController',
Implement explicit build step ordering in Harbormaster Summary: This implements support for explicitly marking the sequence of build steps. Users can now drag and re-order build steps in plans, and artifact dependencies are re-calculated so that if you move "Run Command" before "Lease Host", the "Run Command" step has it's artifact setting cleared and thus the step becomes invalid. Test Plan: Re-ordered build steps and observed dependencies being correctly recalculated. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7715
2013-12-06 04:12:15 +01:00
'HarbormasterPlanOrderController' => 'HarbormasterController',
Formalize "manual" buildables in Harbormaster Summary: Ref T1049. Generally, it's useful to separate test/trial/manual runs from production/automatic runs. For example, you don't want to email a bunch of people that the build is broken just because you messed something up when writing a new build plan. You'd rather try it first, then promote it into production once you have some good runs. Similarly, test runs generally should not affect the outside world, etc. Finally, some build steps (like "wait for other buildables") may want to behave differently when run in production/automation than when run in a testing environment (where they should probably continue immediately). So, formalize the distinction between automatic buildables (those created passively by the system in response to events) and manual buildables (those created explicitly by users). Add filtering, and stop the automated parts of the system from interacting with the manual parts (for example, we won't show manual results on revisions). This also moves the "Apply Build Plan" to a third, new home: instead of the sidebar or Buildables, it's now on plans. I think this generally makes more sense given how things have developed. Broadly, this improves isolation of test environments. Test Plan: Created some builds, browsed around, used filters, etc. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7824
2013-12-26 19:40:43 +01:00
'HarbormasterPlanRunController' => 'HarbormasterController',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterPlanViewController' => 'HarbormasterPlanController',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterPublishFragmentBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'HarbormasterRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Remove PHID database, add Harbormaster database Summary: - We currently write every PHID we generate to a table. This was motivated by two concerns: - **Understanding Data**: At Facebook, the data was sometimes kind of a mess. You could look at a random user in the ID tool and see 9000 assocs with random binary data attached to them, pointing at a zillion other objects with no idea how any of it got there. I originally created this table to have a canonical source of truth about PHID basics, at least. In practice, our data model has been really tidy and consistent, and we don't use any of the auxiliary data in this table (or even write it). The handle abstraction is powerful and covers essentially all of the useful data in the app, and we have human-readable types in the keys. So I don't think we have a real need here, and this table isn't serving it if we do. - **Uniqueness**: With a unique key, we can be sure they're unique, even if we get astronomically unlucky and get a collision. But every table we use them in has a unique key anyway. So we actually get pretty much nothing here, except maybe some vague guarantee that we won't reallocate a key later if the original object is deleted. But it's hard to imagine any install will ever have a collision, given that the key space is 36^20 per object type. - We also currently use PHIDs and Users in tests sometimes. This is silly and can break (see D2461). - Drop the PHID database. - Introduce a "Harbormaster" database (the eventual CI tool, after Drydock). - Add a scratch table to the Harbormaster database for doing unit test meta-tests. - Now, PHID generation does no writes, and unit tests are isolated from the application. - @csilvers: This should slightly improve the performance of the large query-bound tail in D2457. Test Plan: Ran unit tests. Ran storage upgrade. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: csilvers, aran, nh, edward Differential Revision: https://secure.phabricator.com/D2466
2012-05-20 23:46:01 +02:00
'HarbormasterScratchTable' => 'HarbormasterDAO',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterSleepBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Implement interface for adding, editing and deleting build steps on plans. Summary: This implements an interface for adding new build steps, editing existing build steps and deleting build steps from build plans. It uses the settings definitions on the build implementation to work out what fields should be displayed on the edit page. Test Plan: See screenshots: {F78529} {F78532} {F78528} {F78531} {F78527} {F78530} Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7500
2013-11-05 22:54:03 +01:00
'HarbormasterStepAddController' => 'HarbormasterController',
'HarbormasterStepDeleteController' => 'HarbormasterController',
'HarbormasterStepEditController' => 'HarbormasterController',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterTargetWorker' => 'HarbormasterWorker',
Rename "BuildStepImplementation" to "HarbormasterBuildStepImplementation" Summary: Ref T1049. D8588 already required custom code to change what it extends, so this is as good a time as we're going to get to move to more standard class name. Test Plan: `arc liberate`; `arc lint` Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8601
2014-03-26 00:09:21 +01:00
'HarbormasterThrowExceptionBuildStep' => 'HarbormasterBuildStepImplementation',
Render build status on revisions and commits Summary: This uses an event listener to render the status of builds on their buildables. The revision and commit view now renders out the status of each of the builds. Currently the revision controller has the results for the latest diff rendered out. We might want to show the status of previous diffs in the future, but for now I think the latest diff should do fine. There's also a number of bug fixes in this diff, including a particularly nasty one where builds would have a build plan PHID generated for them, which resulted in handle lookups always returning invalid objects. Test Plan: Ran builds against diffs and commits, saw them appear on the revision and commit view controllers. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7544
2013-11-10 00:02:07 +01:00
'HarbormasterUIEventListener' => 'PhabricatorEventListener',
Rename concrete Harbormaster step implementations Summary: Ref T1049. For consistency, rename these to "Harbormaster...". Test Plan: Ran migration, ran builds, everything still works fine. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D8602
2014-03-26 00:09:51 +01:00
'HarbormasterUploadArtifactBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
'HarbormasterWaitForPreviousBuildStepImplementation' => 'HarbormasterBuildStepImplementation',
Split Harbormaster workers apart so build steps can run in parallel Summary: Ref T1049. Currently, the Harbormaster worker looks like this: foreach (step) { run_step(step); } This means steps can't ever be run in parallel. Instead, split it into two workers. The "Build" worker starts things off, and basically does: update_build(); (We could theoretically do this in the original process because it should never take very long, but since there's a lock and it's a little bit complex it seemed cleaner to separate it.) The "Target" worker runs an individual target (like a command, or an HTTP request, or whatever), then updates the build: run_one_step(step); update_build(); The new `update_build()` mechanism in `HarbormasterBuildEngine` does this, roughly: figure_out_overall_status_of_all_steps(); if (build is done) { done(); } if (build is fail) { fail(); } foreach (step that is ready to run) { queue_target_worker_for_step(step); } So, overall: - The part of the code that updates Builds is completely separated from the part of the code that updates Targets. - Targets can run in parallel. Test Plan: - Ran a bunch of builds via `bin/harbormaster build`. - Ran a bunch of builds via web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7890
2014-01-06 21:32:10 +01:00
'HarbormasterWorker' => 'PhabricatorWorker',
Herald skeleton.
2011-03-22 21:22:40 +01:00
'HeraldAction' => 'HeraldDAO',
'HeraldApplyTranscript' => 'HeraldDAO',
Move Herald application capabilities to newer infrastructure Summary: Ref T603. Use the new hotness. Test Plan: Edited Herald in Applications, tried to create rules / global rules without capabilities, got reasonable error messages. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7263
2013-10-09 22:44:41 +02:00
'HeraldCapabilityManageGlobalRules' => 'PhabricatorPolicyCapability',
Rename "HeraldObjectAdapter" to "HeraldAdapter" Summary: Ref T2769. The term "Object" is redundant. Test Plan: grep Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6655
2013-08-02 17:38:17 +02:00
'HeraldCommitAdapter' => 'HeraldAdapter',
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',
Rename "HeraldObjectAdapter" to "HeraldAdapter" Summary: Ref T2769. The term "Object" is redundant. Test Plan: grep Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6655
2013-08-02 17:38:17 +02:00
'HeraldDifferentialRevisionAdapter' => 'HeraldAdapter',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldDisableController' => 'HeraldController',
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',
Remove HeraldActionConfig, HeraldFieldConfig Summary: Ref T2769. Move all of this stuff into Adapters and get rid of the hard-coded classes. I cheated in two places. Test Plan: Edited and activated Herald rules. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6688
2013-08-06 20:23:01 +02:00
'HeraldInvalidActionException' => 'Exception',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'HeraldInvalidConditionException' => 'Exception',
'HeraldInvalidFieldException' => 'Exception',
Add herald support for Maniphest Summary: standing on the shoulders of the badass work to move Maniphest to ApplicationTransactions, this diff implements a few methods and adds an adapter class. For now, we can add cc and flag tasks. I figure see what people ask for? Ref T1368. Test Plan: created herald rules for title and description text hits. made tasks and verified CC and flags worked. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T1368, T1638 Differential Revision: https://secure.phabricator.com/D7122
2013-09-25 20:50:15 +02:00
'HeraldManiphestTaskAdapter' => 'HeraldAdapter',
Herald 'new rule type' interface.
2011-03-22 22:34:38 +01:00
'HeraldNewController' => 'HeraldController',
Add PHIDs to Herald Rules Summary: Ref T2769. Precursor to various Herald-related modernizations. Test Plan: Ran migration; loaded Herald via web. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6648
2013-08-02 15:11:25 +02:00
'HeraldPHIDTypeRule' => 'PhabricatorPHIDType',
Integrate Pholio with Herald Summary: Ref T2766. Does the integration via ApplicationTransactionsEditor. Only did addCC and Flag for proof of concept. Test Plan: Made a rule to cc, made a rule to flag. They worked! (will attach screens to diff) Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2766 Differential Revision: https://secure.phabricator.com/D6766
2013-08-15 22:10:45 +02:00
'HeraldPholioMockAdapter' => 'HeraldAdapter',
Allow Herald pre-commit rules to act on repository projects Summary: Fixes T4264. Adds: - New "Repository's projects" field to Herald pre-commit rules, so you can write global rules which act based on projects. - Allows pre-ref/pre-content rules to bind to projects, and fire for all repositories in that project, so users with limited power can write rules which apply to many repositories. - The pre-ref and pre-content classes were starting to share a fair amount of code, so I made them both extend an abstract base class. Test Plan: Wrote new pre-ref and pre-content rules bound to projects, then pushed commits into repositories in those projects and not in those projects. The "repository projects" field populated, and the rules fired for repositories in the relevant projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4264 Differential Revision: https://secure.phabricator.com/D7883
2014-01-03 21:24:28 +01:00
'HeraldPreCommitAdapter' => 'HeraldAdapter',
'HeraldPreCommitContentAdapter' => 'HeraldPreCommitAdapter',
'HeraldPreCommitRefAdapter' => 'HeraldPreCommitAdapter',
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',
Give Herald rules a standard "Hnnn" object name Summary: Allow Herald rules to be referred to with `H123`, etc., like other object types are. Herald rules now have proper PHIDs and an increasingly prominent role in triggering application actions. Although I suspect users will rarely use `H123` in Remarkup to mention rules, this can simplify some of the interfaces which relate objects across systems. Test Plan: Looked at various interfaces and saw `H123` names. Mentioned `H123` in remarkup. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7786
2013-12-18 21:00:18 +01:00
'HeraldRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Make HeraldRule implement PhabricatorPolicyInterface Summary: Ref T603. Ref T2769. Herald currently interacts with policies in a bad way; specifically, I can create a rule which emails me for everything, and thus learn about objects I can't otherwise see. This shouldn't be possible, so I'm going to reduce personal rules to have only the viewer's scope. For global rules, I think I'm always going to let any user edit them, but make who the rule acts as part of the configuration. There will be an option to make a rule omnipotent, but only admins (or some other special subset of users) will be able to select it. Transactions/subscriptions will provide a check against users editing global rules in ways that are bad. Test Plan: Next diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2769 Differential Revision: https://secure.phabricator.com/D6649
2013-08-02 15:21:43 +02:00
'HeraldRule' =>
array(
0 => 'HeraldDAO',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
1 => 'PhabricatorFlaggableInterface',
2 => 'PhabricatorPolicyInterface',
Remove deprecated `PhabricatorIRCBot` class. Summary: This class has been deprecated for a while (see rP574bc3ba31cca2767bafe7844d7f854d90d6be1c). It should be safe to remove now. Test Plan: N/A Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9469
2014-06-11 14:49:52 +02:00
3 => 'PhabricatorDestructableInterface',
Make HeraldRule implement PhabricatorPolicyInterface Summary: Ref T603. Ref T2769. Herald currently interacts with policies in a bad way; specifically, I can create a rule which emails me for everything, and thus learn about objects I can't otherwise see. This shouldn't be possible, so I'm going to reduce personal rules to have only the viewer's scope. For global rules, I think I'm always going to let any user edit them, but make who the rule acts as part of the configuration. There will be an option to make a rule omnipotent, but only admins (or some other special subset of users) will be able to select it. Transactions/subscriptions will provide a check against users editing global rules in ways that are bad. Test Plan: Next diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2769 Differential Revision: https://secure.phabricator.com/D6649
2013-08-02 15:21:43 +02:00
),
Horrendously rough cut of Herald rule editor.
2011-03-22 23:27:52 +01:00
'HeraldRuleController' => 'HeraldController',
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',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldRuleEditor' => 'PhabricatorApplicationTransactionEditor',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'HeraldRuleListController' => 'HeraldController',
Make HeraldRuleQuery policy-aware Summary: Ref T2769. dem policy checks Test Plan: Loaded `/herald/`; loaded rule editor. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6650
2013-08-02 15:38:17 +02:00
'HeraldRuleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Herald Summary: Ref T2769. Ref T2625. Herald is currently a giant mishmash of hard-codes and weird special cases. Move toward modernization and normality. Test Plan: {F52716} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2769 Differential Revision: https://secure.phabricator.com/D6652
2013-08-02 15:53:01 +02:00
'HeraldRuleSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add ApplicationTransactions to Herald Summary: Ref T2769. I'm planning to keep this pretty simple, but we have this ad-hoc edit log for rules already and some other mess that we can clean up. Test Plan: No effect yet; see future changes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6654
2013-08-02 17:28:55 +02:00
'HeraldRuleTransaction' => 'PhabricatorApplicationTransaction',
'HeraldRuleTransactionComment' => 'PhabricatorApplicationTransactionComment',
Add a normal "view" page for Herald rules Summary: Ref T2769. This will house the transaction list and replace the "edit log" stuff. The UI is a little bit rough and can probably share more code with the transaction history, but seems mostly-reasonable. Test Plan: {F53253} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2769 Differential Revision: https://secure.phabricator.com/D6690
2013-08-06 22:43:45 +02:00
'HeraldRuleViewController' => 'HeraldController',
Very rough cut at Herald test console.
2011-03-24 21:49:21 +01:00
'HeraldTestConsoleController' => 'HeraldController',
Allow Herald rules to be disabled, instead of deleted Summary: Ref T603. Ref T1279. Further improves transaction and policy support for Herald. - Instead of deleting rules (which wipes out history and can't be undone) allow them to be disabled. - Track disables with transactions. - Gate disables with policy controls. - Show policy and status information in the headers. - Show transaction history on rule detail screens. - Remove the delete controller. - Support disabled queries in the ApplicationSearch. Test Plan: - Enabled and disabled rules. - Searched for enabled/disabled rules. - Verified disabled rules don't activate. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1279, T603 Differential Revision: https://secure.phabricator.com/D7247
2013-10-07 02:10:29 +02:00
'HeraldTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Migrate all Differential reviewer data to edges Summary: Ref T1279. @champo did a lot of this work already; we've been doing double writes for a long time. Add "double reads" (reading the edge table as both the "relationship" table and as the "reviewer status" table), and migrate all the data. I'm not bothering to try to recover old reviewer status (e.g., we could infer from transactions who accepted old revisions) because it wold be very complicated and doesn't seem too valuable. Test Plan: - Without doing the migration, used Differential. Verified that reads and writes worked. Most of the data was there anyway since we've been double-writing. - Performed the migration. Verified that everything was still unchanged. - Dropped the edge table, verified all reviweer data vanished. - Migrated again, verified the reviewer stuff was restored. - Did various cc/reviewer/subscriber queries, got consistent results. Reviewers: btrahan Reviewed By: btrahan CC: champo, aran Maniphest Tasks: T1279 Differential Revision: https://secure.phabricator.com/D7227
2013-10-05 22:48:45 +02:00
'HeraldTranscript' =>
array(
0 => 'HeraldDAO',
1 => 'PhabricatorPolicyInterface',
),
Rough cut of herald transcripts and Differential adapter.
2011-03-25 05:32:26 +01:00
'HeraldTranscriptController' => 'HeraldController',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'HeraldTranscriptGarbageCollector' => 'PhabricatorGarbageCollector',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'HeraldTranscriptListController' => 'HeraldController',
Make Herald transcripts policy-aware Summary: Ref T603. Herald transcripts potentially leak a bunch of content (task text, revision/commit content). Don't let users see them if they can't see the actual objects. This is a little messy but ends up mostly reasonable-ish. Test Plan: - Verified that transcripts for objects I couldn't see no longer appear in the list, and reject access. - Verified that transcripts for objects in applications I can't see reject access, albeit less gracefully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7221
2013-10-05 00:17:18 +02:00
'HeraldTranscriptQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Herald - add application search for transcripts Summary: this diff also makes the "test console" appear with the main search nav *and* updates application search to use the page title as the crumb rather than just search. Fixes T4399. Test Plan: queried for transcript ids - success! queried for TX and MX - success! saved the TX and MX query and it worked again! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4399 Differential Revision: https://secure.phabricator.com/D8297
2014-02-21 21:51:25 +01:00
'HeraldTranscriptSearchEngine' => 'PhabricatorApplicationSearchEngine',
Truncate object fields in Herald transcripts Summary: A few users have hit cases where Herald transcripts of large commits exceed the MySQL packet limit, because one of the fields in the transcript is an enomrous textual diff. There's no value in saving these huge amounts of data. Transcripts are useful for understanding the action of Herald rules, but can be reconstructed later. Instead of saving all of the data, limit each field to 4KB of data. For strings, we just truncate at 4KB. For arrays, we truncate after 4KB of values. Test Plan: Ran unit tests. Artificially decreased limit and ran transcripts, saw them truncate properly. Reviewers: btrahan Reviewed By: btrahan CC: frgtn, aran Differential Revision: https://secure.phabricator.com/D7783
2013-12-18 20:59:53 +01:00
'HeraldTranscriptTestCase' => 'PhabricatorTestCase',
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',
Allow configuration of default document policies for Legalpad Summary: Ref T3116. User request / generally modern feature. Test Plan: Set defaults to whacky projects and created a new document; it defaulted appropriately. Reviewers: btrahan Reviewed By: btrahan CC: aran, allan.laal Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D8110
2014-01-30 20:47:42 +01:00
'LegalpadCapabilityDefaultEdit' => 'PhabricatorPolicyCapability',
'LegalpadCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadController' => 'PhabricatorController',
'LegalpadDAO' => 'PhabricatorLiskDAO',
'LegalpadDocument' =>
array(
0 => 'LegalpadDAO',
1 => 'PhabricatorPolicyInterface',
2 => 'PhabricatorSubscribableInterface',
3 => 'PhabricatorApplicationTransactionInterface',
),
'LegalpadDocumentBody' =>
array(
0 => 'LegalpadDAO',
1 => 'PhabricatorMarkupInterface',
),
'LegalpadDocumentCommentController' => 'LegalpadController',
'LegalpadDocumentEditController' => 'LegalpadController',
'LegalpadDocumentEditor' => 'PhabricatorApplicationTransactionEditor',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'LegalpadDocumentListController' => 'LegalpadController',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Legalpad - remarkup LX to link to LX Summary: standard ish. Fixes T4388. Test Plan: made a comment with L1 and noted L1 linked to L1. Also observed working-ish hovercard. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4388 Differential Revision: https://secure.phabricator.com/D8178
2014-02-10 20:27:08 +01:00
'LegalpadDocumentRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentSearchEngine' => 'PhabricatorApplicationSearchEngine',
Legalpad - add signature page Summary: Fixes T3481. Sort of - this thing be very ugly. Also it assumes that you'll "always" want to sign terms. I was thinking in a future diff that should be optional as well as configurable, though it was unclear to me if either was worth pursuing... Generally very hideous as the three main elements (PHUIDocument, AphrontErrorView, and AphrontForm with an AphrontFormInset) have never really played together before. Test Plan: agreed to some test terms. noted UI displayed nicely. reloaded and noted UI told me I had signed it already. Went to different terms and filled them out wrong and got sensical errors. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3481 Differential Revision: https://secure.phabricator.com/D6399
2013-07-10 20:46:39 +02:00
'LegalpadDocumentSignController' => 'LegalpadController',
Legalpad - add a view signatures page Summary: ...needs to add a LegalpadDocumentSignatureQuery class to get this done, which is also re-deployed everywhere we were issuing raw queries. Ref T3116. Test Plan: viewed some signatures. Verified color and footer icons showed up how I wanted them to. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7986
2014-01-17 20:40:26 +01:00
'LegalpadDocumentSignature' =>
array(
0 => 'LegalpadDAO',
1 => 'PhabricatorPolicyInterface',
),
'LegalpadDocumentSignatureListController' => 'LegalpadController',
'LegalpadDocumentSignatureQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Legalpad - make it work for not logged in users Summary: Adds "verified" and "secretKey" to Legalpad document signatures. For logged in users using an email address they own, things are verified right away. Otherwise, the email is sent a verification letter. When the user clicks the link the signature is marked verified. Test Plan: signed the document with a bogus email address not logged in. verified the email that would be sent looked good from command line. followed link and successfully verified bogus email address Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, asherkin Maniphest Tasks: T4283 Differential Revision: https://secure.phabricator.com/D7930
2014-01-15 02:17:18 +01:00
'LegalpadDocumentSignatureVerificationController' => 'LegalpadController',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadDocumentViewController' => 'LegalpadController',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'LegalpadMockMailReceiver' => 'PhabricatorObjectMailReceiver',
'LegalpadReplyHandler' => 'PhabricatorMailReplyHandler',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'LegalpadTransaction' => 'PhabricatorApplicationTransaction',
'LegalpadTransactionComment' => 'PhabricatorApplicationTransactionComment',
'LegalpadTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'LegalpadTransactionType' => 'LegalpadConstants',
'LegalpadTransactionView' => 'PhabricatorApplicationTransactionView',
Implement a more compact, general database-backed key-value cache Summary: See discussion in D4204. Facebook currently has a 314MB remarkup cache with a 55MB index, which is slow to access. Under the theory that this is an index size/quality problem (the current index is on a potentially-384-byte field, with many keys sharing prefixes), provide a more general index with fancy new features: - It implements PhutilKeyValueCache, so it can be a component in cache stacks and supports TTL. - It has a 12-byte hash-based key. - It automatically compresses large blocks of data (most of what we store is highly-compressible HTML). Test Plan: - Basics: - Loaded /paste/, saw caches generate and save. - Reloaded /paste/, saw the page hit cache. - GC: - Ran GC daemon, saw nothing. - Set maximum lifetime to 1 second, ran GC daemon, saw it collect the entire cache. - Deflate: - Selected row formats from the database, saw a mixture of 'raw' and 'deflate' storage. - Used profiler to verify that 'deflate' is fast (12 calls @ 220us on my paste list). - Ran unit tests Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D4259
2012-12-21 23:17:56 +01:00
'LiskChunkTestCase' => 'PhabricatorTestCase',
Add regression test for LiskDAO::__call() Summary: D3606 Test Plan: Deleted `call()`, ran the test. Reviewers: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D3814
2012-10-24 21:47:53 +02:00
'LiskDAOTestCase' => 'PhabricatorTestCase',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskEphemeralObjectException' => 'Exception',
Provide isolated, read/write storage fixtures for unit tests Summary: - Unit tests can request storage fixtures. - We build one fixture across all tests in the process, which can quickstart (takes roughly 1s to build, 200ms to destroy for me). This is a one-time cost for running an arbitrary number of fixture-based tests. - We isolate all the connections inside transactions for each test, so individual tests don't affect one another. Test Plan: Ran unit tests, which cover the important properties of fixtures. Reviewers: btrahan, vrana, jungejason, edward Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T140 Differential Revision: https://secure.phabricator.com/D2345
2012-05-02 21:42:23 +02:00
'LiskFixtureTestCase' => 'PhabricatorTestCase',
Provide connection isolation to Lisk and enable it by default in tests Summary: Allow Lisk to be put into process-isolated mode which establishes only isolated connections. By default, put it into this mode when running unit tests. Build some simple unit tests around object insertion and updating. NOTE: The one flaw in this is that $dao->establishConnection() still punches through the isolation layer. I need to do an API change to fix this though so I'm holding it for now. It will probably just rename getConnection() to establishConnection() and then rename establishConnection() to something scary like establishLiveExternalConnection(). Test Plan: Ran unit tests. Reviewed By: aran Reviewers: aran, tuomaspelkonen, jungejason CC: aran, epriestley Differential Revision: 194
2011-04-30 19:11:59 +02:00
'LiskIsolationTestCase' => 'PhabricatorTestCase',
'LiskIsolationTestDAO' => 'LiskDAO',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'LiskIsolationTestDAOException' => 'Exception',
Add PhutilFactsUpateIterator Summary: This iterator processes objects that have been updated. Test Plan: Ran this test script: $cursor = null; $table = new DifferentialRevision(); while (true) { $iterator = new PhabricatorFactsUpdateIterator($table, $cursor); foreach ($iterator as $new_cursor => $update) { echo "{$new_cursor} => D".$update->getID()."\n"; $cursor = $new_cursor; } echo "Zzz...\n"; sleep(5); } Verified it iterated over every object and then stopped. Made a comment on a differenial revision, verified it iterated over the object after 15 seconds. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3077
2012-07-26 22:09:36 +02:00
'LiskMigrationIterator' => 'PhutilBufferedIterator',
Add LiskRawMigrationIterator Summary: Ref T2222. I need this to migrate the Differential comment tables, because they are large. We have the similar `LiskMigrationIterator` already, but it won't work here because I intend to destroy the original objects after migrating them. Test Plan: Wrote a script to iterate over the `differential_comment` table, got reasonable output: {P869} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D6264
2013-06-21 21:55:07 +02:00
'LiskRawMigrationIterator' => 'PhutilBufferedIterator',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ManiphestActionMenuEventListener' => 'PhabricatorEventListener',
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',
Add capabilities for editing task triage details (priority, assignee, etc) Summary: This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions. Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces. Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
'ManiphestCapabilityBulkEdit' => 'PhabricatorPolicyCapability',
Add defualt view and default edit policies for tasks Summary: Ref T603. Allow global default policies to be configured for tasks. Test Plan: - Created task via web UI. - Created task via Conduit. - Created task via email. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7267
2013-10-09 22:53:17 +02:00
'ManiphestCapabilityDefaultEdit' => 'PhabricatorPolicyCapability',
'ManiphestCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Add capabilities for editing task triage details (priority, assignee, etc) Summary: This is primarily a client request, and a little bit use-case specific, but policies seem to be holding up well and I'm getting more comfortable about maintaining this. Much if it can run through ApplicationTransactions. Allow the ability to edit status, policies, priorities, assignees and projects of a task to be restricted to some subset of users. Also allow bulk edit to be locked. This affects the editor itself and the edit, view and list interfaces. Test Plan: As a restricted user, created, edited and commented on tasks. Tried to drag them around. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7357
2013-10-22 01:59:06 +02:00
'ManiphestCapabilityEditAssign' => 'PhabricatorPolicyCapability',
'ManiphestCapabilityEditPolicies' => 'PhabricatorPolicyCapability',
'ManiphestCapabilityEditPriority' => 'PhabricatorPolicyCapability',
'ManiphestCapabilityEditProjects' => 'PhabricatorPolicyCapability',
'ManiphestCapabilityEditStatus' => 'PhabricatorPolicyCapability',
Convert maniphest to use standard fields Summary: Ref T3794. Drop auxiliary field, use standard field. Test Plan: Performed migration, field seemed to survive it intact. Edited and viewed tasks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794 Differential Revision: https://secure.phabricator.com/D7036
2013-09-19 20:56:15 +02:00
'ManiphestConfiguredCustomField' =>
array(
0 => 'ManiphestCustomField',
1 => 'PhabricatorStandardCustomFieldInterface',
),
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',
Make Maniphest custom fields extend PhabricatorCustomField Summary: Ref T418. These implementations share no method names, so we can safely just move Maniphest fields into the `PhabricatorCustomField` hierarchy. Replaces two Maniphest-specific custom field exceptions which nothing catches. Test Plan: Viewed Maniphest, edited/altered custom fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6927
2013-09-11 00:31:48 +02:00
'ManiphestCustomField' => 'PhabricatorCustomField',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
Bring "fixes x as y" parser forward and use new parsers instead of old ones Summary: Fixes T3872. Ref T1812. Ref T3886. Modernize the "closes x as y" string parser, and use all the new parsers instead of the old ones. Test Plan: Made a commit full of a pile of these trigger strings, then used `scripts/repository/reparse.php --message` to reparse it. Verified that parses came back as expected using a bunch of `var_dump()`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1812, T3872, T3886 Differential Revision: https://secure.phabricator.com/D8263
2014-02-18 00:59:13 +01:00
'ManiphestCustomFieldStatusParser' => 'PhabricatorCustomFieldMonogramParser',
'ManiphestCustomFieldStatusParserTestCase' => 'PhabricatorTestCase',
Provide generalized custom field storage and custom field indexes in Maniphest Summary: Ref T418. Depends on D6992. This adds index and value storage for Maniphest custom fields. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D6995
2013-09-16 23:06:41 +02:00
'ManiphestCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'ManiphestCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Maniphest wireframes Summary: Test Plan: Reviewers: CC:
2011-02-08 19:53:59 +01:00
'ManiphestDAO' => 'PhabricatorLiskDAO',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ManiphestEdgeEventListener' => 'PhabricatorEventListener',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ManiphestHovercardEventListener' => 'PhabricatorEventListener',
Provide and populate an object name index for Maniphest Summary: See discussion in D6955. This provides a table we can JOIN against to (effectively) "ORDER BY project name", populates it intially, and keeps it up to date as projects are edited. Test Plan: - Ran storage upgrade, verified projects populated into the table. - Edited a project, verified its entry updated. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6957
2013-09-12 22:06:44 +02:00
'ManiphestNameIndex' => 'ManiphestDAO',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'ManiphestNameIndexEventListener' => 'PhabricatorEventListener',
Use Application PHIDs in Maniphest Summary: Ref T2715. Switch Maniphest to the new stuff. Test Plan: Used `phid.query`; `phid.lookup` to load objects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6516
2013-07-21 21:05:28 +02:00
'ManiphestPHIDTypeTask' => 'PhabricatorPHIDType',
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',
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',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'ManiphestStatusConfigOptionType' => 'PhabricatorConfigJSONOptionType',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
4 => 'PhabricatorFlaggableInterface',
5 => 'PhrequentTrackableInterface',
6 => 'PhabricatorCustomFieldInterface',
Allow users to remove their own comments, and administrators to remove any comment Summary: Fixes T4909. Adds a "remove" link next to the edit link, which permanently hides a comment. Addresses two use cases: - Allowing administrators to clean up spam. - Allowing users to try to put the genie back in the bottle if they post passwords or sensitive links, etc. The user who removed the comment is named in the removal text to enforce some level of administrative accountability. No data is deleted, but there's currently no method to restore these comments. We'll see if we need one. This is cheating a little bit by storing "removed" as "2" in the isDeleted field. This doesn't seem tooooo bad for now. Test Plan: - Removed some of my comments. - As an administrator, removed other users' comments. - Failed to view history of a removed comment. - Failed to edit a removed comment. - Failed to remove a removed comment. - Verified feed doesn't show the old comment after comment removal. Reviewers: btrahan Reviewed By: btrahan Subscribers: qgil, chad, epriestley Maniphest Tasks: T4909 Differential Revision: https://secure.phabricator.com/D8945
2014-05-05 19:55:32 +02:00
7 => 'PhabricatorDestructableInterface',
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
),
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',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskListController' => 'ManiphestController',
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',
Make ManiphestTaskQuery a (mostly) policy-aware query Summary: Ref T603. Test Plan: Viewed home and maniphest, fiddled all the knobs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D6930
2013-09-10 16:53:27 +02:00
'ManiphestTaskQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'ManiphestTaskResultListView' => 'ManiphestView',
Introduce ManiphestTaskSearchEngine plus ManiphestTaskListControllerPro Summary: Ref T603. Ref T2625. Cutting this over is tricky because of Maniphest's existing saved queries. Plan here is: - Build out the "pro" controller at `/maniphest/query/`. - Once it's at parity, migrate custom queries. - Nuke the old UI. This provides a minimal implementation with no filter support. Test Plan: Looked at `/maniphest/query/`, saw results technically available. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6933
2013-09-10 19:04:26 +02:00
'ManiphestTaskSearchEngine' => 'PhabricatorApplicationSearchEngine',
Slightly improve Maniphest documentation.
2011-07-04 22:04:22 +02:00
'ManiphestTaskStatus' => 'ManiphestConstants',
Add config validation for task status config Summary: Ref T1812. This still doesn't expose configuration to the user, but adds validation for it. Test Plan: Added a pile of unit tests. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8584
2014-03-25 22:04:51 +01:00
'ManiphestTaskStatusTestCase' => 'PhabricatorTestCase',
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',
Rename ManiphestTransactionPro -> ManiphestTransaction Summary: Ref T2217. Pro is the new standard. Test Plan: Lots of `grep`, made a pile of Maniphest views/edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7093
2013-09-24 19:49:06 +02:00
'ManiphestTransaction' => 'PhabricatorApplicationTransaction',
Route all ManiphestTransaction reads through a single class Summary: Ref T2217. I'm going to do the fake-double-writes ("double reads"?) thing where we proxy the storage that worked pretty well for auth. That is: - (Some more cleanup diffs next, maybe?) - Move all the data to the new storage, and make `ManiphestTransaction` read and write by wrapping `ManiphestTransactionPro`. - If nothing breaks, it's a straight shot to nuking ManiphestTransaction callsite by callsite. I think Maniphest is way easier than Differential, because there are very few query sites and no inline comments. Test Plan: `grep` to find callsites. Loaded task view, called Conduit. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7067
2013-09-23 23:25:14 +02:00
'ManiphestTransactionComment' => 'PhabricatorApplicationTransactionComment',
Remove "ManiphestTransactionEditorPro" Summary: Drop the "Pro" bit. Test Plan: Created/edited tasks, moved tasks around, generally made a mess. Nothing burned down. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7352
2013-10-22 01:58:37 +02:00
'ManiphestTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
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',
Migrate all Maniphest transaction data to new storage Summary: Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except: - The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so: - When migrating, "edit" + "comment" transactions need to be split in two. - When editing now, we should no longer combine these transaction types. - These changes are pretty straightforward and low-impact. - This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though. Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other. Test Plan: - Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly. - Droped the test data and performed the migration. - Looked at the resulting data for obvious discrepancies. - Looked at a bunch of tasks and their transaction history. - Used Conduit to pull transaction data. - Edited task description and clicked "View Details" on transaction. - Used batch editor. - Made a bunch more edits. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2217 Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 23:25:28 +02:00
'ManiphestTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
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
'ManiphestView' => 'AphrontView',
Add a GC for sent and received mail Summary: Ref T4368. We don't currently GC these tables, and the sent mail table is one of the largest on `secure.phabricator.com`. There's no value in retaining this information indefinitely. Instead, retain it for 90 days, which should be plenty of time to debug/diagnose any issues. Test Plan: Ran `phd debug garbage`, saw it clean up a reasonable amount of data from these tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8127
2014-02-03 19:51:31 +01:00
'MetaMTAMailReceivedGarbageCollector' => 'PhabricatorGarbageCollector',
'MetaMTAMailSentGarbageCollector' => 'PhabricatorGarbageCollector',
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',
Naunce - capalities for Source object Summary: another little piece here that basically just adds some permissions to source editing. serving it up before I do anything too complicated to make sure it seems kosher. in terms of what comes next this form needs to be dynamic based on source type so there'll be some fun there. That said, I plan to implement a more simple "phabricator form" only version to start here and flesh out a few other things like queues with that. Test Plan: set permission to no one for source edit and got a nice error page. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7535
2013-11-08 21:45:14 +01:00
'NuanceCapabilitySourceDefaultEdit' => 'PhabricatorPolicyCapability',
'NuanceCapabilitySourceDefaultView' => 'PhabricatorPolicyCapability',
'NuanceCapabilitySourceManage' => 'PhabricatorPolicyCapability',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceController' => 'PhabricatorController',
'NuanceDAO' => 'PhabricatorLiskDAO',
'NuanceItem' =>
array(
0 => 'NuanceDAO',
1 => 'PhabricatorPolicyInterface',
),
'NuanceItemEditController' => 'NuanceController',
'NuanceItemEditor' => 'PhabricatorApplicationTransactionEditor',
'NuanceItemQuery' => 'NuanceQuery',
'NuanceItemTransaction' => 'NuanceTransaction',
'NuanceItemTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceItemTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'NuanceItemViewController' => 'NuanceController',
'NuancePHIDTypeItem' => 'PhabricatorPHIDType',
'NuancePHIDTypeQueue' => 'PhabricatorPHIDType',
'NuancePHIDTypeRequestor' => 'PhabricatorPHIDType',
'NuancePHIDTypeSource' => 'PhabricatorPHIDType',
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuancePhabricatorFormSourceDefinition' => 'NuanceSourceDefinition',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'NuanceQueue' =>
array(
0 => 'NuanceDAO',
1 => 'PhabricatorPolicyInterface',
),
'NuanceQueueEditController' => 'NuanceController',
'NuanceQueueEditor' => 'PhabricatorApplicationTransactionEditor',
'NuanceQueueItem' => 'NuanceDAO',
'NuanceQueueQuery' => 'NuanceQuery',
'NuanceQueueTransaction' => 'NuanceTransaction',
'NuanceQueueTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceQueueTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'NuanceQueueViewController' => 'NuanceController',
'NuanceRequestor' => 'NuanceDAO',
'NuanceRequestorEditController' => 'NuanceController',
'NuanceRequestorEditor' => 'PhabricatorApplicationTransactionEditor',
'NuanceRequestorQuery' => 'NuanceQuery',
'NuanceRequestorSource' => 'NuanceDAO',
'NuanceRequestorTransaction' => 'NuanceTransaction',
'NuanceRequestorTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceRequestorTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'NuanceRequestorViewController' => 'NuanceController',
'NuanceSource' =>
array(
0 => 'NuanceDAO',
1 => 'PhabricatorPolicyInterface',
),
Nuance - federate out the design of NuanceSource via NuanceSourceDefinition Summary: ...and get the basic edit flow "working" for a new NuanceSourceDefinition - the Phabricator Form. ...and fix a dumb bug in the query class so when you redirect to the view page / try to edit an existing NuanceSource you don't fatal. Test Plan: played around with the edit form and it worked! Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7585
2013-11-20 22:41:19 +01:00
'NuanceSourceDefinition' => 'Phobject',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'NuanceSourceEditController' => 'NuanceController',
'NuanceSourceEditor' => 'PhabricatorApplicationTransactionEditor',
'NuanceSourceQuery' => 'NuanceQuery',
'NuanceSourceTransaction' => 'NuanceTransaction',
'NuanceSourceTransactionComment' => 'PhabricatorApplicationTransactionComment',
'NuanceSourceTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'NuanceSourceViewController' => 'NuanceController',
'NuanceTransaction' => 'PhabricatorApplicationTransaction',
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',
PHUIButtonBarView Summary: Adds a handy bar full of tiny buttons. Use only when directed. Ref: T4394 Test Plan: View UI Examples. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8169
2014-02-10 20:11:36 +01:00
'PHUIButtonBarExample' => 'PhabricatorUIExample',
'PHUIButtonBarView' => 'AphrontTagView',
PHUIButtonView class Summary: Rough pass at a PHUIButtonView Class. Keeps phutil_tag intact and adds some image features if you use the class. Test Plan: UIExamples Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6192
2013-06-13 03:23:35 +02:00
'PHUIButtonExample' => 'PhabricatorUIExample',
'PHUIButtonView' => 'AphrontTagView',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PHUICalendarListView' => 'AphrontTagView',
Modernize Calendar View Summary: Updates Calendar View to more modern components. Test Plan: Browse Calendar Forward and Back, Create a Status, Get Excited, Get PUMPED. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4392 Differential Revision: https://secure.phabricator.com/D8247
2014-02-16 18:25:29 +01:00
'PHUICalendarMonthView' => 'AphrontView',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PHUICalendarWidgetView' => 'AphrontTagView',
Color Palette Summary: Picked a set of standard colors. Based on our current Maniphest color set, but tweaked to the same hue with http://color.hailpixel.com/ Test Plan: Not intended to be end all be all, but a decent first cut. Applied to Maniphest and Tags. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Differential Revision: https://secure.phabricator.com/D6229
2013-06-19 00:35:14 +02:00
'PHUIColorPalletteExample' => 'PhabricatorUIExample',
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',
Update Form Layouts Summary: This attempts some consistency in form layouts. Notably, they all now contain headers and are 16px off the sides and tops of pages. Also updated dialogs to the same look and feel. I think I got 98% of forms with this pass, but it's likely I missed some buried somewhere. TODO: will take another pass as consolidating these colors and new gradients in another diff. Test Plan: Played in my sandbox all week. Please play with it too and let me know how they feel. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6806
2013-08-26 20:53:11 +02:00
'PHUIFormLayoutView' => 'AphrontView',
Add a basic multipage form Summary: Ref T2232. Very busy day on IRC so I feel like I've made 20 minutes of progress in 1-minute spurts here, but this adds the basics for a form that can have multiple pages and automatically handle pagination and reading to/from the request, objects and responses. The UIExample is reasonably instructive. Basically, you make a form, add pages to the form, and add controls to the pages. The core flow control looks like this: if ($request->isFormPost()) { $form->readFromRequest($request); // (1) if ($form->isComplete()) { // (2) $response = $form->writeToResponse($response); // (3) // Process result here. // (4) } } else { $form->readFromObject($object); // (5) } The key parts are: # This reads the form state from the request, including reading all the inactive pages. # This tests if all pages are valid and the user just clicked "Done" on the last page. # This produces a "response", which might be writing to an object (for simpler forms) or creating a transaction record (for more complex forms). # Here, we would save the object or apply the transactions. # When the user views the form for the first time, we preload all the values from some object (which might just be empty). Ultimate goal here is to fix repository creation to not be a terrible pit of awfulness. There are probably a lot of rough edges and missing features still, but this seems to not be totally crazy. I'm using two submit buttons with different names which doesn't work on IE7 or something, but we can JS our way out of that if we need to. Test Plan: Paged forward and backward through the form. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2232 Differential Revision: https://secure.phabricator.com/D6003
2013-05-23 23:39:01 +02:00
'PHUIFormMultiSubmitControl' => 'AphrontFormControl',
'PHUIFormPageView' => 'AphrontView',
Policy, Status in PHUIHeaderView Summary: The adds the ability to set 'properties' such as state, privacy, due date to the header of objects. Test Plan: Implemented in Paste, Pholio. Tested various states. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7016
2013-09-17 18:12:37 +02:00
'PHUIHeaderView' => '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',
PHUIInfoPanel Summary: First cut of an 'info panel' for phabricator. Basic concept is for display a list of items with a bit more info and depth and an object item list. Projects could be a good first example. Test Plan: UIExamples Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7398
2013-10-25 20:09:06 +02:00
'PHUIInfoPanelExample' => 'PhabricatorUIExample',
'PHUIInfoPanelView' => 'AphrontView',
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',
Move PHUIFormBoxView to PHUIObjectBoxView Summary: I'd like to reuse this for other content areas, renaming for now. This might be weird to keep setForm, but I can fix that later if we need. Test Plan: reload a few forms in maniphest, projects, differential Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D7120
2013-09-25 20:23:29 +02:00
'PHUIObjectBoxView' => 'AphrontView',
Move PhabricatorObjectItem to PHUIObjectItem, add 'plain' setting for lists. Summary: Adds plain support for object lists that just look like lists Test Plan: review UIexamples and a number of other applications Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6922
2013-09-09 23:14:34 +02:00
'PHUIObjectItemListExample' => 'PhabricatorUIExample',
'PHUIObjectItemListView' => 'AphrontTagView',
'PHUIObjectItemView' => 'AphrontTagView',
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',
Update pinboard view styles, move to PHUI Summary: Tightens up the CSS to display more items (4 wide on 15") and fixes some mobile CSS issues with appseach. Fixes T3614 Test Plan: Tested Pholio, Macros, mobile layouts Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3614 Differential Revision: https://secure.phabricator.com/D6694
2013-08-07 19:58:09 +02:00
'PHUIPinboardItemView' => 'AphrontView',
'PHUIPinboardView' => 'AphrontView',
PHUIPropertyListView Summary: This builds out and implements PHUIPropertyListView (container) and PHUIPropertyListItemView (section) as well as adding tabs. Test Plan: Tested each page I edited with the exception of Releeph and Phortune, though those changes look ok to me diff wise. Updated examples page with tabs. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7283
2013-10-11 16:53:56 +02:00
'PHUIPropertyGroupView' => 'AphrontTagView',
'PHUIPropertyListExample' => 'PhabricatorUIExample',
'PHUIPropertyListView' => 'AphrontView',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PHUIRemarkupPreviewPanel' => 'AphrontTagView',
Add PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PHUIStatusItemView' => 'AphrontTagView',
'PHUIStatusListView' => 'AphrontTagView',
Move PhabricatorTagView to PHUITagView Summary: For consistency and great justice. Test Plan: tested audit, uiexamples, action headers Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7967
2014-01-14 23:09:52 +01:00
'PHUITagExample' => 'PhabricatorUIExample',
'PHUITagView' => 'AphrontView',
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',
PHUITimelineView Summary: Updates PhabricatorTimeline to PHUITimeline. Uses standard colors and spacing, softens up the actors, and reduces visual spacing of action-only events. - Also updated some 2x sprite images. Test Plan: Tested Tasks Paste and Pholio in my sandbox. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8205
2014-02-12 18:02:05 +01:00
'PHUITimelineEventView' => 'AphrontView',
'PHUITimelineExample' => 'PhabricatorUIExample',
'PHUITimelineView' => 'AphrontView',
Move Workboards to PHUI Summary: This is just renaming to PHUI (I like shorter text :) Test Plan: reload workboard examples page, seems to not fatal and looks very appealing Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Differential Revision: https://secure.phabricator.com/D6904
2013-09-06 23:06:12 +02:00
'PHUIWorkboardExample' => 'PhabricatorUIExample',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PHUIWorkboardView' => 'AphrontTagView',
'PHUIWorkpanelView' => 'AphrontTagView',
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',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphraseAbstractKey' => 'Phobject',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseController' => 'PhabricatorController',
'PassphraseCredential' =>
array(
0 => 'PassphraseDAO',
1 => 'PhabricatorPolicyInterface',
),
Add a credential selection control to Passphrase Summary: Ref T4122. Adds a control for choosing credentials. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran, lsave Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7617
2013-11-21 21:35:36 +01:00
'PassphraseCredentialControl' => 'AphrontFormControl',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialCreateController' => 'PassphraseController',
'PassphraseCredentialDestroyController' => 'PassphraseController',
'PassphraseCredentialEditController' => 'PassphraseController',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PassphraseCredentialListController' => 'PassphraseController',
Add a "Lock Permanently" action to Passphrase Summary: Fixes T4931. Each new credential should come with the ability to lock the credential permanently, so that no one can ever edit again. Each existing credential must allow user to lock existing credential. Test Plan: Create new credential, verify that you can lock it before saving it. Open existing unlocked credential, verify that option to lock it exists. Once credential is locked, the option to reveal it should be disabled, and editing the credential won't allow username/password updates. Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4931 Differential Revision: https://secure.phabricator.com/D8947
2014-05-03 03:05:19 +02:00
'PassphraseCredentialLockController' => 'PassphraseController',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialPublicController' => 'PassphraseController',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PassphraseCredentialRevealController' => 'PassphraseController',
'PassphraseCredentialSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PassphraseCredentialTransaction' => 'PhabricatorApplicationTransaction',
'PassphraseCredentialTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PassphraseCredentialTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PassphraseCredentialType' => 'Phobject',
'PassphraseCredentialTypePassword' => 'PassphraseCredentialType',
Allow Passphrase to generate SSH keypairs and extact public keys from private keys Summary: Ref T4587. - Add an option to generate a keypair. - Add an option to view the public keys for existing keypairs. Test Plan: - Generated keypairs. - Viewed public keys. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8515
2014-03-13 02:58:25 +01:00
'PassphraseCredentialTypeSSHGeneratedKey' => 'PassphraseCredentialTypeSSHPrivateKey',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseCredentialTypeSSHPrivateKey' => 'PassphraseCredentialType',
'PassphraseCredentialTypeSSHPrivateKeyFile' => 'PassphraseCredentialTypeSSHPrivateKey',
'PassphraseCredentialTypeSSHPrivateKeyText' => 'PassphraseCredentialTypeSSHPrivateKey',
'PassphraseCredentialViewController' => 'PassphraseController',
'PassphraseDAO' => 'PhabricatorLiskDAO',
'PassphrasePHIDTypeCredential' => 'PhabricatorPHIDType',
Add "PassphraseKey" classes for code which needs to actually use credentials Summary: Ref T4122. These classes provide typed, checked access to credentials, so you can say "give me this password, and throw if anything is funky". Test Plan: Used in next revision. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7625
2013-11-23 00:23:10 +01:00
'PassphrasePasswordKey' => 'PassphraseAbstractKey',
'PassphraseSSHKey' => 'PassphraseAbstractKey',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PassphraseSecret' => 'PassphraseDAO',
Modernize policies in Paste and Macro Summary: Ref T603. Fixes T2823. This updates Paste and Macro. - **Paste** - Added default view policy. - I didn't add a "create" policy, since I can't come up with any realistic scenario where you'd give users access to pastes but not let them create them. - **Macro** - Added a "manage" policy, which covers creating and editing macros. This lets an install only allow "People With An Approved Sense of Humor" or whatever to create macros. - Removed the "edit" policy, since giving individual users access to specific macros doesn't make much sense to me. - Changed the view policy to the "most public" policy the install allows. - Added view policy information to the header. Also fix a couple of minor things in Maniphest. Test Plan: - Set Paste policy, created pastes via web and Conduit, saw they got the right default policies. - Set Macro policy, tried to create/edit macros with valid and unauthorized users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2823, T603 Differential Revision: https://secure.phabricator.com/D7317
2013-10-16 19:35:52 +02:00
'PasteCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PasteCreateMailReceiver' => 'PhabricatorMailReceiver',
Paste 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',
Paste - add support for email replies and subscribers Summary: Email replies and subscribers seem to go hand in hand so deploy both at once. Test Plan: played around with bin/mail. Verified replies posted comments on the paste. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3650 Differential Revision: https://secure.phabricator.com/D6682
2013-08-06 02:11:46 +02:00
'PasteMockMailReceiver' => 'PhabricatorObjectMailReceiver',
'PasteReplyHandler' => 'PhabricatorMailReplyHandler',
Add a granular capability for user directory browsing Summary: Fixes T4358. User request from IRC, but I think this is generally reasonable. Although we can not prevent users from determining that other user accounts exist in the general case, it does seem reasonable to restrict browsing the user directory to a subset of users. In our case, I'll probably do this on `secure.phabricator.com`, since it seems a little odd to let Google index the user directory, for example. Test Plan: Set the policy to "no one" and tried to browse users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4358 Differential Revision: https://secure.phabricator.com/D8112
2014-01-30 20:53:49 +01:00
'PeopleCapabilityBrowseUserDirectory' => 'PhabricatorPolicyCapability',
Add a GC for user logs Summary: Fixes T4368. This is the last "obvious" table we have which we should be GC'ing but do not. It's about 1/12th of the data on `secure.phabricator.com`. This table stores logins, account creation, password resets, login attempts, etc, and is primarily useful if something sketchy happens so you can go back and review login activity. This data is not useful indefinitely, and there's no reason to retain it forever. Because you don't always know when something sketchy happened I've given this table a fairly long TTL (180 days), but we don't need limitless amounts of this data. Test Plan: Ran `phd debug garbage` and saw a reasonable amount of data get GC'd. This table already has an appropriate key. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4368 Differential Revision: https://secure.phabricator.com/D8128
2014-02-03 19:51:41 +01:00
'PeopleUserLogGarbageCollector' => 'PhabricatorGarbageCollector',
I guess this can support JS too.
2011-01-30 01:16:09 +01:00
'Phabricator404Controller' => 'PhabricatorController',
Add Disqus, Facebook, Google, GitHub auth config; AWS config Summary: Also improve behavior for the "unknown config" warning. Test Plan: Looked at configs, went through unknown config workflow. Reviewers: btrahan, codeblock Reviewed By: btrahan CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4310
2013-01-01 23:09:29 +01:00
'PhabricatorAWSConfigOptions' => 'PhabricatorApplicationConfigOptions',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorAccessControlTestCase' => 'PhabricatorTestCase',
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',
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',
Add a `./bin/aphlict build` workflow. Summary: Currently, it is a bit tricky to build the Aphlict client SWF from the ActionScript source. Provide a `./bin/aphlict build` workflow that simplifies this process. Depends on D9226. Test Plan: Executed the workflow: ``` > ./bin/aphlict build Done. ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9338
2014-06-07 20:33:55 +02:00
'PhabricatorAphlictManagementBuildWorkflow' => 'PhabricatorAphlictManagementWorkflow',
Make `./bin/aphlict` behave more like a service. Summary: Fixes T5126. Provide `start`, `stop`, `restart`, `debug` and `status` workflows for `./bin/aphlict`. This makes it easier to manage Aphlict as if it were a service. Test Plan: ``` > sudo ./bin/aphlict status Aphlict is not running. > sudo ./bin/aphlict stop Aphlict is not running. > sudo ./bin/aphlict start Aphlict Server started. > sudo ./bin/aphlict status Aphlict (12880) is running. > sudo ./bin/aphlict restart Stopping Aphlict Server (12880)... Aphlict Server (12880) exited normally. Aphlict Server started. > sudo ./bin/aphlict stop Stopping Aphlict Server (12895)... Aphlict Server (12895) exited normally. > sudo ./bin/aphlict debug Starting Aphlict server in foreground... Launching server: $ node '/usr/src/phabricator/src/applications/aphlict/management/../../../../support/aphlict/server/aphlict_server.js' --port='22280' --admin='22281' --host='localhost' --user='aphlict' [Fri May 30 2014 09:56:14 GMT+0000 (UTC)] Started Server (PID 12911) ``` Reviewers: #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: hach-que, epriestley, Korvin Maniphest Tasks: T5126 Differential Revision: https://secure.phabricator.com/D9226
2014-06-05 21:13:44 +02:00
'PhabricatorAphlictManagementDebugWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementRestartWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStartWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStatusWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementStopWorkflow' => 'PhabricatorAphlictManagementWorkflow',
'PhabricatorAphlictManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
Provide hasChildren() to replace isEmptyContent() Summary: Fixes T3698. Sometimes views need to render differently depending on whether they contain content or not. The existing approach for this is `isEmptyContent()`, which doesn't work well and is sort of hacky (it implies double-rendering content, which is not always free or side-effect free). Instead, provide a test for an element without children. This test is powerful enough to catch the easy cases of `null`, etc., and just do the expected thing, but will not catch a View which is reduced upon rendering. Since this is rare and we have no actual need for it today, just accept that as a limitation. Test Plan: Viewed Timeline and Feed UI examples. Viewed Feed (feed), Pholio (timelineview), and Differential (old transactionview). {F53915} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3698 Differential Revision: https://secure.phabricator.com/D6718
2013-08-12 16:51:01 +02:00
'PhabricatorAphrontViewTestCase' => 'PhabricatorTestCase',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorAppSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorApplication' => 'PhabricatorPolicyInterface',
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',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorApplicationDashboard' => '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 remarkup support for Asana URIs Summary: Ref T2852. Primarily, this expands API access to Asana. As a user-visible effect, it links Asana tasks in Remarkup. When a user enters an Asana URI, we register an onload behavior to make an Ajax call for the lookup. This respects privacy imposed by the API without creating a significant performance impact. Test Plan: {F47183} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6274
2013-06-25 00:55:08 +02:00
'PhabricatorApplicationDoorkeeper' => '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 application policies to be edited Summary: Ref T603. Enables: - Application policies can be edited. - Applications can define custom policies (this will be used for setting defaults, like "what is the default visibiltiy of new tasks", and meta-policies, like "who can create a task?"). Test Plan: Edited application policies. A future diff does more with custom policies. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7205
2013-10-03 21:40:08 +02:00
'PhabricatorApplicationEditController' => 'PhabricatorApplicationsController',
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',
Harbormaster v(-2) Summary: Ref T1049. I don't really want to sink too much time into this right now, but a seemingly reasonable architecture came to me in a dream. Here's a high-level overview of how things fit together: - **"Build"**: In Harbormaster, "build" means any process we want to run against a working copy. It might actually be building an executable, but it might also be running lint, running unit tests, generating documentation, generating symbols, running a deploy, setting up a sandcastle, etc. - `HarbormasterBuildable`: A "buildable" is some piece of code which build operations can run on. Generally, this is either a Differential diff or a Diffusion commit. The Buildable class just wraps those objects and provides a layer of abstraction. Currently, you can manually create a buildable from a commit. In the future, this will be done automatically. - `HarbormasterBuildStep`: A "build step" is an individual build operation, like "run lint", "run unit", "build docs", etc. The step defines how to perform the operation (for example, "run unit tests by executing 'arc unit'"). In this diff, this barely exists. - `HarbormasterBuildPlan`: This glues together build steps into groups or sequences. For example, you might want to "run unit", and then "deploy" if the tests pass. You can create a build plan which says "run step "unit tests", then run step "deploy" on success" or whatever. In the future, these will also contain triggers/conditions ("Automatically run this build plan against every commit") and probably be able to define failure actions ("If this plan fails, send someone an email"). Because build plans will run commands, only administrators can manage them. - `HarbormasterBuild`: This is the concrete result of running a `BuildPlan` against a `Buildable`. It tracks the build status and collects results, so you can see if the build is running/successful/failed. A `Buildable` may have several `Build`s, because you can execute more than one `BuildPlan` against it. For example, you might have a "documentation" build plan which you run continuously against HEAD, but a "unit" build plan which you want to run against every commit. - `HarbormasterBuildTarget`: This is the concrete result of running a `BuildStep` against a `Buildable`. These are children of `Build`. A step might be able to produce multiple targets, but generally this is something like "Unit Tests" or "Lint" and has an overall status, so you can see at a glance that unit tests were fine but lint had some issues. - `HarbormasterBuildItem`: An optional subitem for a target. For lint, this might be an individual file. For unit tests, an individual test. For normal builds, an executable. For deploys, a server. For documentation generation, there might just not be subitems. - `HarbormasterBuildLog`: Provides extra information, like command/execution transcripts. This is where stdout/stderr will get dumped, and general details and other messages. - `HarbormasterBuildArtifact`: Stores side effects or results from build steps. For example, something which builds a binary might put the binary in "Files" and then put its PHID here. Unit tests might put coverage information here. Generally, any build step which produces some high-level output object can use this table to record its existence. This diff implements almost nothing and does nothing useful, but puts most of these object relationships in place. The two major things you can't easily do with these objects are: 1) Run arbitrary cron jobs. Jenkins does this, but it feels tacked on and I don't know of anyone using it for that. We could create fake Buildables to get a similar effect, but if we need to do this I'd rather do it elsewhere in general. Build and cron/service/monitoring feel like pretty different problems to me. 2) Run parameterized/matrix steps (maybe?). Bamboo has this plan/stage/task/job breakdown where a build step can generate a zillion actual jobs, like "build client on x86", "build server on x86", "build client on ARM", "build server on ARM", etc. We can sort of do this by having a Step map to multiple Targets, but I haven't really thought about it too much and it may end up being not-great. I'd guess we have like an 80% chance of getting a clean implementation if/when we get there. I suspect no one actually needs this, or when they do they'll just implement a custom Step and it can be parameterized at that level. I'm not too worried about this overall. The major difference between this and Jenkins/Bamboo/TravisCI is that all three of those are **plan-centric**: the primary object in the system is a build plan, and the dashboard shows you all your build plans and the current status. I don't think this is the right model. One disadvantage is that you basically end up with top-level messaging that says "Trunk is broken", not "Trunk was broken by commit af32f392f". Harbormaster is **buildable-centric**: the primary object in the system is stuff you can run build operations against (commits/branches/revisions), and actual build plans are secondary. The main view will be "recent commits on this branch, and whether they're good or not" -- which I think is what's most important in a larger/more complex product -- not the pass/fail status of all jobs. This also makes it easier and more natural to integrate with Differential and Diffusion, which both care about the overall status of the commit/revision, not the current status of jobs. Test Plan: Poked around, but this doesn't really do anything yet. Reviewers: btrahan Reviewed By: btrahan CC: zeeg, chad, aran, seporaitis Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7368
2013-10-23 00:01:06 +02:00
'PhabricatorApplicationHarbormaster' => 'PhabricatorApplication',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorApplicationHelp' => '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',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorApplicationHome' => 'PhabricatorApplication',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorApplicationLaunchView' => 'AphrontTagView',
Legalpad V0.1 Summary: got some basics here -- - can create document - creates document object and document body object and cross-reference - can update document - creates document body object and updates reference from document object - contributors stored correctly - a contributor is anyone who has created or updated a legal document - can subscribe to documents - can flag documents - can comment on documents - can query for documents based on creator and create range - uses basically modern stuff Missing stuff -- - T3488 - T3483 - T3482 - T3481 - T3480 - T3479 Test Plan: TRUNCATED the database. From scratch made 3 legal docs. Verified versions and version were correct in document and document body database entries respectively. Left comments and verified versions and version did not update. Left updates and verified those updated versions and version. Flagged document and verified it showed up on homepage. Subscribed and verified transaction showed up. Reviewers: epriestley Reviewed By: epriestley CC: chad, aran, Korvin Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D6351
2013-07-03 20:15:45 +02:00
'PhabricatorApplicationLegalpad' => 'PhabricatorApplication',
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',
Slightly modernize Aphlict server status page Summary: Ref T4324. Add a real `Application` class. Use modern UI elements. @chad, we could use an icon :3 Test Plan: {F114477} Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8254
2014-02-18 01:00:19 +01:00
'PhabricatorApplicationNotifications' => 'PhabricatorApplication',
Nuance - get some scaffolding up there Summary: I updated the wiki too - https://secure.phabricator.com/w/projects/pebkac/ - with what I am thinking right now. Rough plan here is - next diff: - implement editors and transactions - implement "web type" for contact source - /pebkac/item/new/ will be the entry point for this - implement "actions" on a contact - probably some "polish" on the scaffolding laid out here; like "create" permissions maybs - diffs after that: - implement "twitter" type for source - implement email reply handler stuff for item and source Probs a great time to blast huge holes in all this stuff. :D Test Plan: these pages load and arc lint doesn't complain Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran, chad Differential Revision: https://secure.phabricator.com/D7465
2013-11-07 02:00:09 +01:00
'PhabricatorApplicationNuance' => 'PhabricatorApplication',
Fix an anchor redirect issue with OAuth server, plus modernize the application a bit Summary: Ref T4593. Via HackerOne. An attacker can use the anchor reattachment, combined with the Facebook token workflow, combined with redirection on OAuth errors to capture access tokens. The attack works roughly like this: - Create an OAuth application on Phabricator. - Set the domain to `evil.com`. - Grab the OAuth URI for it (something like `https://phabricator.com/oauthserver/auth/?redirect_uri=http://evil.com&...`). - Add an invalid `scope` parameter (`scope=xyz`). - Use //that// URI to build a Facebook OAuth URI (something like `https://facebook.com/oauth/?redirect_uri=http://phabricator.com/...&response_type=token`). - After the user authorizes the application on Facebook (or instantly if they've already authorized it), they're redirected to the OAuth server, which processes the request. Since this is the 'token' workflow, it has auth information in the URL anchor/fragment. - The OAuth server notices the `scope` error and 302's to the attacker's domain, preserving the anchor in most browsers through anchor reattachment. - The attacker reads the anchor in JS and can do client workflow stuff. To fix this, I've made several general changes/modernizations: - Add a new application and make it beta. This is mostly cleanup, but also turns the server off for typical installs (it's not generally useful quite yet). - Add a "Console" page to make it easier to navigate. - Modernize some of the UI, since I was touching most of it anyways. Then I've made specific security-focused changes: - In the web-based OAuth workflow, send back a human-readable page when errors occur. I //think// this is universally correct. Previously, humans would get a blob of JSON if they entered an invalid URI, etc. This type of response is correct for the companion endpoint ("ServerTokenController") since it's called by programs, but I believe not correct for this endpoint ("AuthController") since it's used by humans. Most of this is general cleanup (give humans human-readable errors instead of JSON blobs). - Never 302 off this endpoint automatically. Previously, a small set of errors (notably, bad `scope`) would cause a 302 with 'error'. This exposes us to anchor reattachment, and isn't generally helpful to anyone, since the requesting application did something wrong and even if it's prepared to handle the error, it can't really do anything better than we can. - The only time we'll 'error' back now from this workflow is if a user explicitly cancels the workflow. This isn't a 302, but a normal link (the cancel button), so the anchor is lost. - Even if the application is already approved, don't blindly 302. Instead, show the user a confirmation dialog with a 'continue' link. This is perhaps slightly less user-friendly than the straight redirect, but I think it's pretty reasonable in general, and it gives us a lot of protection against these classes of attack. This redirect is then through a link, not a 302, so the anchor is again detached. - Test Plan: I attempted to hit everything I touched. See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4593 Differential Revision: https://secure.phabricator.com/D8517
2014-03-13 20:59:10 +01:00
'PhabricatorApplicationOAuthServer' => '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',
Add more application query capabilities Summary: Make the application query a little more flexible, and formalize the PHID type. Test Plan: See next diffs. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7201
2013-10-03 21:39:15 +02:00
'PhabricatorApplicationPHIDTypeApplication' => 'PhabricatorPHIDType',
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
'PhabricatorApplicationPHPAST' => 'PhabricatorApplication',
Passphrase v0 Summary: Ref T4122. Implements a credential management application for the uses described in T4122. @chad, this needs an icon, HA HA HAHA HA BWW HA HA HA bwahaha Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4122 Differential Revision: https://secure.phabricator.com/D7608
2013-11-20 18:13:35 +01:00
'PhabricatorApplicationPassphrase' => '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',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhabricatorApplicationPhragment' => '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',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorApplicationPolicy' => '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',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorApplicationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorApplicationSupport' => 'PhabricatorApplication',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorApplicationSystem' => 'PhabricatorApplication',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorApplicationTest' => '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',
Allow structured destruction of Differential Revisions Summary: Ref T4749. Ref T3265. Ref T4909. - Remove old "destroy revision" script. - Move to structured `bin/remove` destruction. - Fix some edge issues. - Add transaction destruction support. Test Plan: - Destroyed a bunch of revisions. - Saw diffs, changesets, hunks, transactions, edges, and inlines also get wiped out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4749, T4909, T3265 Differential Revision: https://secure.phabricator.com/D8943
2014-05-02 03:25:30 +02:00
2 => 'PhabricatorDestructableInterface',
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
),
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',
Allow structured destruction of Differential Revisions Summary: Ref T4749. Ref T3265. Ref T4909. - Remove old "destroy revision" script. - Move to structured `bin/remove` destruction. - Fix some edge issues. - Add transaction destruction support. Test Plan: - Destroyed a bunch of revisions. - Saw diffs, changesets, hunks, transactions, edges, and inlines also get wiped out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4749, T4909, T3265 Differential Revision: https://secure.phabricator.com/D8943
2014-05-02 03:25:30 +02:00
3 => 'PhabricatorDestructableInterface',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
),
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentEditController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentEditor' => 'PhabricatorEditor',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionCommentHistoryController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionCommentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a quote action to Differential and Maniphest Summary: Ref T4119. This is ugly for now, but technically works. The comment area and transaction log don't realy know about each other, so for the moment the linking is a bit manual. Differential/Maniphest are special cases anyway. Test Plan: {F149992} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4119 Differential Revision: https://secure.phabricator.com/D8957
2014-05-05 19:55:58 +02:00
'PhabricatorApplicationTransactionCommentQuoteController' => 'PhabricatorApplicationTransactionController',
Allow users to remove their own comments, and administrators to remove any comment Summary: Fixes T4909. Adds a "remove" link next to the edit link, which permanently hides a comment. Addresses two use cases: - Allowing administrators to clean up spam. - Allowing users to try to put the genie back in the bottle if they post passwords or sensitive links, etc. The user who removed the comment is named in the removal text to enforce some level of administrative accountability. No data is deleted, but there's currently no method to restore these comments. We'll see if we need one. This is cheating a little bit by storing "removed" as "2" in the isDeleted field. This doesn't seem tooooo bad for now. Test Plan: - Removed some of my comments. - As an administrator, removed other users' comments. - Failed to view history of a removed comment. - Failed to edit a removed comment. - Failed to remove a removed comment. - Verified feed doesn't show the old comment after comment removal. Reviewers: btrahan Reviewed By: btrahan Subscribers: qgil, chad, epriestley Maniphest Tasks: T4909 Differential Revision: https://secure.phabricator.com/D8945
2014-05-05 19:55:32 +02:00
'PhabricatorApplicationTransactionCommentRemoveController' => 'PhabricatorApplicationTransactionController',
Add previews to ApplicationTransaction Summary: Implements previews for Macros and Pholio. (Design is nonfinal -- kind of split the difference between `diff_full_view.png`, laziness, and space concerns. Next couple diffs will add more stuff here.) Test Plan: {F28055} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, vrana Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4246
2012-12-21 14:51:33 +01:00
'PhabricatorApplicationTransactionCommentView' => 'AphrontView',
Allow ApplicationTransaction comments to be edited and deleted Summary: Allows you to edit or delete comments in appplications which support ApplicationTransactions. UI/UX stuff: - The dialogs are rough but I want to do a dialog design pass more generally, @chad has some mocks. - When you add new mentions via edit, they don't currently count as mentions. I'm not sure what I want to do about this. - When you edit or delete a comment, we do not publish any notifications about it. I think this is reasonable. - I didn't separate "delete" out versus "edit"; I assume it will be reasonably intuitive that deleting all the text deletes effectively deletes the comment. I also want to discourage deletion somewhat (we still show the transaction, just show that the comment has been deleted). Test Plan: Transaction view, note "Edit" and "Edited" links: {F26914} Edit view, has some design issues but I want to do a pass on dialogs in general: {F26915} History view: {F26913} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T1082 Differential Revision: https://secure.phabricator.com/D4149
2012-12-11 23:01:51 +01:00
'PhabricatorApplicationTransactionController' => 'PhabricatorController',
Transactions - make the details stuff generic and ajaxy Summary: Fixes T2213 Test Plan: Updated a pholio mock description. Observed that when I first showed details there was a round trip made. Toggled show / hide noting no more trips made to server. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T2213 Differential Revision: https://secure.phabricator.com/D6801
2013-08-23 01:45:14 +02:00
'PhabricatorApplicationTransactionDetailController' => 'PhabricatorApplicationTransactionController',
Genericize transactions in Pholio Summary: Split Pholio's transaction implementation into generic and application-specific parts. Moves us toward generic transactions, with support for: - Editing and deleting comments. - Setting visibility of individual comments (I'm not a fan of this feature but we'll see). I want to move everything to a more generic piece of infrastructure but there's very little they can share right now so adding transactions to, e.g., Paste or Macros (T2157) means massive amounts of similar code. Tons of work left to do here, but I think it basically works. Here's a screenshot: {F26820} Test Plan: Made transactions in Pholio. Reviewers: btrahan, vrana, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4136
2012-12-11 22:59:20 +01:00
'PhabricatorApplicationTransactionEditor' => 'PhabricatorEditor',
Add feed integration to generic transactions Summary: Publish feed stories, including from Pholio. Actual stories are somewhat garbage but it's all display-time; I'm going to do a pass on feed in general. Test Plan: {F26832} Reviewers: btrahan, chad, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2104 Differential Revision: https://secure.phabricator.com/D4140
2012-12-11 23:00:21 +01:00
'PhabricatorApplicationTransactionFeedStory' => 'PhabricatorFeedStory',
Add ApplicationTransaction handling for transactions with no effect Summary: When a user submits an action with no effect (like an empty comment, an "abandon" on an already-accepted revision, or a "close, resolved" on a closed task) we want to alert them that their action isn't effective. These warnings fall into two general buckets: - User is submitting two or more actions, and some aren't effective but some are. Prompt them to apply the effective actions only. - A special case of this is where the only effective action is a comment. We provide tailored text ("Post Comment") in this case. - User is submitting one action, which isn't effective. Tell them they're out of luck. - A special case of this is an empty comment. We provide tailored text in this case. By default, the transaction editor throws when transactions have no effect. The caller can then deal with this, or use `PhabricatorApplicationTransactionNoEffectResponse` to provide a standard dialog that gives the user information as above. For cases where we expect transactions to have no effect (notably, "edit" forms) we just continue on no-effect unconditionally. Also fix an issue where new, combined or filtered transactions would not be represented properly in the Ajax response (i.e., return final transactions from `applyTransactions()`), and translate some strings. Test Plan: - Submitted empty and nonempy comments in Macro and Pholio. - Submitted comments with new and existing "@mentions". - Submitted edits in both applications. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T912, T2104 Differential Revision: https://secure.phabricator.com/D4160
2012-12-12 02:27:40 +01:00
'PhabricatorApplicationTransactionNoEffectException' => 'Exception',
'PhabricatorApplicationTransactionNoEffectResponse' => 'AphrontProxyResponse',
Use application PHIDs for application transactions Summary: Ref T2715. Ref T3578. Load application transactions through application PHID infrastructure. Test Plan: Viewed feed, saw successful loads of application transaction objects and rendered feed stories. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6617
2013-07-29 15:51:19 +02:00
'PhabricatorApplicationTransactionPHIDTypeTransaction' => 'PhabricatorPHIDType',
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',
Improve ApplicationTransaction behavior for poorly constructed transactions Summary: Ref T2222. Five very small improvements: - I hit this exception and it took a bit to understand which transaction was causing problems. Add an `Exception` subclass which does a better job of making the message debuggable. - The `oldValue` of a transaction may be `null`, legitimately (for example, changing the `repositoryPHID` for a revision from `null` to some valid PHID). Do a check to see if `setOldValue()` has been called, instead of a check for a `null` value. - Add an additional check for the other case (shouldn't have a value, but does). - When we're not generating a value, don't bother calling the code to generate it. The best case scenario is that it has no effect; any effect it might have (changing the value) is always wrong. - Maniphest didn't fall back to the parent correctly when computing this flag, so it got the wrong result for `CustomField` transactions. Test Plan: Resolved the issue I was hitting more easily, made updates to a `null`-valued custom field, and applied other normal sorts of transactions successfully. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4557, T2222 Differential Revision: https://secure.phabricator.com/D8401
2014-03-05 19:44:21 +01:00
'PhabricatorApplicationTransactionStructureException' => 'Exception',
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',
Allow custom fields to have validation logic Summary: Ref T418. This is fairly messy, but basically: - Add a validation phase to TransactionEditor. - Add a validation phase to CustomField. - Bring it to StandardField. - Add validation logic for the int field. - Provide support in related classes. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7028
2013-09-19 00:31:58 +02:00
'PhabricatorApplicationTransactionValidationError' => 'Phobject',
'PhabricatorApplicationTransactionValidationException' => 'Exception',
Policy Transactions - add a details view for custom policy Summary: 'cuz those can be complicated. Fixes T4738. I needed to do a fair amount of heavy lifting to get the policy stuff rendering correctly. For now, I made this end point very one purpose and tried to make that clear. Test Plan: looked at some custom policies. see screenshots. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4738 Differential Revision: https://secure.phabricator.com/D8890
2014-04-29 18:42:54 +02:00
'PhabricatorApplicationTransactionValueController' => 'PhabricatorApplicationTransactionController',
Modernize Macro application Summary: Adds feed, email, notifications, comments, partial editing, subscriptions, enable/disable, flags and crumbs to Macro. Test Plan: {F26839} {F26840} {F26841} {F26842} {F26843} {F26844} {F26845} Reviewers: vrana, btrahan, chad Reviewed By: vrana CC: aran Maniphest Tasks: T2157, T175, T2104 Differential Revision: https://secure.phabricator.com/D4141
2012-12-11 23:01:03 +01:00
'PhabricatorApplicationTransactionView' => 'AphrontView',
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',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorApplicationTypeahead' => '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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorApplicationsListController' => 'PhabricatorApplicationsController',
Initial Asana sync for Differential Summary: Ref T2852. This is highly incomplete but seems structurally sound. Some additional context is available in the Google doc. - Add a workspace ID configuration. Without it, nothing else activates. - Add a worker which reacts to feed stories. - Feed stories about things which aren't Differential objects are ignored. - We load the revision, or fail permanently if we can't. - We get all the related user PHIDs (author, reviewers, CCs). - We check if any of them have linked Asana accounts, or fail permanently if they don't. - We check for an "ASANATASK" edge from the revision. - If we do not find one, we create a new task. - If we do find one, we load the task. - If we succeed, we check the chronological key of the most recent synchronized feed story ("cursor"). - If this story is the same or newer, we update the task to synchronize it to the current state of the revision. - If we fail to load the task, we fail permanently ("asana task has been deleted"). - We then publish the actual story text to the task. Not in yet: - Updating followers requires separate API calls which we don't do yet. - No subtasks yet. - No sync of open/closed state. Test Plan: {F47546} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6302
2013-06-26 01:33:16 +02:00
'PhabricatorAsanaConfigOptions' => 'PhabricatorApplicationConfigOptions',
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',
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',
),
Move rendering to SearchEngine for Calendar Summary: Ref T4986. This one needs `getApplicationURI()` so make it a little beefier to deal with that. (It would be vaguely nice to somehow share the handle and application stuff between Controllers and Engine classes like this, but I don't immediately see a clean way to do it without traits. Not a big deal, in any case.) Test Plan: - Viewed Calendar. - Made a Calendar panel. - Viewed feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9012
2014-05-08 18:18:02 +02:00
'PhabricatorAuditListController' => 'PhabricatorAuditController',
Add a basic first-class audit UI Summary: Currently, audits are only accessible through the Owners tool. Start moving them to their own first-class tool in preparation for broader audit integration. - Lay some infrastructure groundwork (e.g. AuditQuery). - Build a basic /audit/ view. - Show audits on the commit page in Diffusion. This has some code duplication with stuff we've already got, but I'll merge everything together as we move forward on this. Test Plan: Looked at /audit/ and a commit. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1685
2012-02-24 22:02:14 +01:00
'PhabricatorAuditListView' => 'AphrontView',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorAuditMailReceiver' => 'PhabricatorObjectMailReceiver',
Provide a more flexible script for administrative management of audits Summary: Fixes T3679. This comes up every so often and the old script is extremely broad (nuke everything in a repository). Provide a more surgical tool. Test Plan: Ran a bunch of variations of the script and they all seemed to work OK. Reviewers: btrahan Reviewed By: btrahan CC: aran, staticshock Maniphest Tasks: T3679 Differential Revision: https://secure.phabricator.com/D6678
2013-08-05 19:35:01 +02:00
'PhabricatorAuditManagementDeleteWorkflow' => 'PhabricatorAuditManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorAuditManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add preview and drafts to audits Summary: Add comment previews and saved drafts to audits, like Maniphest / Differential. Test Plan: Typed stuff into the box. Got a preview. Reloaded page. Stuff was still there. Submitted comment. Stuff is gone. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T904 Differential Revision: https://secure.phabricator.com/D1699
2012-02-27 22:00:23 +01:00
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
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',
Show account cards for external accounts on "linked accounts" screen and "link new account" Summary: Ref T1536. These can probably use some design tweaking and there's a bit of a bug with profile images for some providers, but generally seems to be in the right ballpark. Test Plan: {F46604} {F46605} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6210
2013-06-17 16:08:50 +02:00
'PhabricatorAuthAccountView' => 'AphrontView',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthConfirmLinkController' => 'PhabricatorAuthController',
Authentication
2011-01-26 22:21:12 +01:00
'PhabricatorAuthController' => 'PhabricatorController',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthDAO' => 'PhabricatorLiskDAO',
Allow AuthenticationProviderConfig to be enabled and disabled Summary: Ref T1536. Nothing too exciting here, one TODO about tailoring error messages. Test Plan: {F46403} {F46404} {F46405} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6204
2013-06-17 19:54:08 +02:00
'PhabricatorAuthDisableController' => 'PhabricatorAuthProviderConfigController',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthDowngradeSessionController' => 'PhabricatorAuthController',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthEditController' => 'PhabricatorAuthProviderConfigController',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthFactor' => 'Phobject',
'PhabricatorAuthFactorConfig' => 'PhabricatorAuthDAO',
'PhabricatorAuthFactorTOTP' => 'PhabricatorAuthFactor',
'PhabricatorAuthFactorTOTPTestCase' => 'PhabricatorTestCase',
Require multiple auth factors to establish web sessions Summary: Ref T4398. This prompts users for multi-factor auth on login. Roughly, this introduces the idea of "partial" sessions, which we haven't finished constructing yet. In practice, this means the session has made it through primary auth but not through multi-factor auth. Add a workflow for bringing a partial session up to a full one. Test Plan: - Used Conduit. - Logged in as multi-factor user. - Logged in as no-factor user. - Tried to do non-login-things with a partial session. - Reviewed account activity logs. {F149295} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8922
2014-05-01 19:23:02 +02:00
'PhabricatorAuthFinishController' => 'PhabricatorAuthController',
Add "High Security" mode to support multi-factor auth Summary: Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode". This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots. Test Plan: See guided walkthrough. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8851
2014-04-28 02:31:11 +02:00
'PhabricatorAuthHighSecurityRequiredException' => 'Exception',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthLinkController' => 'PhabricatorAuthController',
Build out Auth UI a little bit Summary: Ref T1536. Make this UI a bit more human-friendly. Test Plan: {F46873} Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6237
2013-06-20 00:00:37 +02:00
'PhabricatorAuthListController' => 'PhabricatorAuthProviderConfigController',
Generalize login flows for new registration Summary: Ref T1536. None of this code is reachable. `PhabricatorAuthLoginController` provides a completely generic login/link flow, similar to how D6155 provides a generic registration flow. `PhabricatorAuthProvider` wraps a `PhutilAuthAdapter` and glues the generic top-level flow to a concrete authentication provider. Test Plan: Static only, code isn't meaningfully reachable. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6159
2013-06-16 19:14:07 +02:00
'PhabricatorAuthLoginController' => 'PhabricatorAuthController',
Provide `bin/auth ldap` for LDAP diagnostics Summary: Ref T1536. Test Plan: Ran `bin/auth ldap`. Reviewers: mbishopim3, chad Reviewed By: mbishopim3 CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6218
2013-06-17 22:26:25 +02:00
'PhabricatorAuthManagementLDAPWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementListFactorsWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add very basic `bin/auth` tool Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in. Test Plan: {F46411} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 19:55:05 +02:00
'PhabricatorAuthManagementRecoverWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth refresh` for debugging OAuth token refresh issues Summary: Ref T2852. Provide a script for inspecting/debugging OAuth token refresh. Test Plan: Ran `bin/auth refresh` with various arguments, saw token refreshes. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6276
2013-06-25 00:55:41 +02:00
'PhabricatorAuthManagementRefreshWorkflow' => 'PhabricatorAuthManagementWorkflow',
Add `bin/auth list-factors` and `bin/auth strip` to remove multi-factor auth Summary: Ref T4398. The major goals here is to let administrators strip auth factors in two cases: - A user lost their phone and needs access restored to their account; or - an install previously used an API-based factor like SMS, but want to stop supporting it (this isn't possible today). Test Plan: - Used `bin/auth list-factors` to show installed factors. - Used `bin/auth strip` with various mixtures of flags to selectively choose and strip factors from accounts. - Also ran `bin/auth refresh` to verify refreshing OAuth tokens works (small `OAuth` vs `OAuth2` tweak). Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8909
2014-04-30 23:30:00 +02:00
'PhabricatorAuthManagementStripWorkflow' => 'PhabricatorAuthManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorAuthManagementWorkflow' => 'PhabricatorManagementWorkflow',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorAuthNeedsApprovalController' => 'PhabricatorAuthController',
Allow installs to require multi-factor authentication for all users Summary: Ref T5089. Adds a `security.require-multi-factor-auth` which forces all users to enroll in MFA before they can use their accounts. Test Plan: Config: {F159750} Roadblock: {F159748} After configuration: {F159749} - Required MFA, got roadblocked, added MFA, got unblocked. - Removed MFA, got blocked again. - Used `bin/auth strip` to strip MFA, got blocked. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T5089 Differential Revision: https://secure.phabricator.com/D9285
2014-06-04 01:50:27 +02:00
'PhabricatorAuthNeedsMultiFactorController' => 'PhabricatorAuthController',
Add initial create screen for auth providers Summary: Ref T1536. Adds an initial "choose a provider type" screen for adding a new provider. This doesn't go anywhere yet. Test Plan: {F46316} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6199
2013-06-17 19:51:35 +02:00
'PhabricatorAuthNewController' => 'PhabricatorAuthProviderConfigController',
Send old login code to the bottom of the sea Summary: Ref T1536. This is extremely reachable and changes the login code to the new stuff. Notes: - I've hard-disabled password registration since I want installs to explicitly flip it on via config if they want it. New installs will get it by default in the future, but old installs shouldn't have their auth options change. - Google doesn't let us change the redirect URI, so keep the old one working. - We need to keep a bit of LDAP around for now for LDAP import. - **Facebook:** This causes substantive changes in what login code is executed. Test Plan: - Logged in / logged out / registered, hit new flows. - Logged in with google. - Verified no password registration by default. Reviewers: btrahan, chad Reviewed By: chad CC: wez, nh, aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6222
2013-06-19 10:33:27 +02:00
'PhabricatorAuthOldOAuthRedirectController' => 'PhabricatorAuthController',
Make password reset emails use one-time tokens Summary: Ref T4398. This code hadn't been touched in a while and had a few crufty bits. **One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne. Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours. **Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address. This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator. However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification. Instead, make the email verification part optional, and use it on welcome links but not other types of links. **Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow. **Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it. Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful. Mitigate this in two ways: - First, send to the actual email address the user entered, not the primary account email address. - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable). **Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one. Previously, this code was static and based on the email address. Instead, issue a one-time code. **Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble. However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row. To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance. **Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit. Test Plan: - **One Time Resets** - Used a reset link. - Tried to reuse a reset link, got denied. - Verified each link is different. - **Coupling of Email Verification and One-Time Login** - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component. - Tried to tack one on, got denied. - Used the welcome email link to login + verify. - Tried to mutate the URI to not verify, or verify something else: got denied. - **Message Customization** - Viewed messages on the different workflows. They seemed OK. - **Reset Emails Going to Main Account Email** - Sent password reset email to non-primary email. - Received email at specified address. - Verified it does not verify the address. - **Password Reset Without Old Password** - Reset password without knowledge of old one after email reset. - Tried to do that without a key, got denied. - Tried to reuse a key, got denied. - **Jump Into Hisec** - Logged in with MFA user, got factor'd, jumped directly into hisec. - Logged in with non-MFA user, no factors, normal password reset. - **Some UI Cleanup** - Viewed new UI. - **Misc** - Created accounts, logged in with welcome link, got verified. - Changed a username, used link to log back in. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 19:41:00 +02:00
'PhabricatorAuthOneTimeLoginController' => 'PhabricatorAuthController',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorAuthPHIDTypeAuthFactor' => 'PhabricatorPHIDType',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfig' =>
array(
0 => 'PhabricatorAuthDAO',
1 => 'PhabricatorPolicyInterface',
),
Add List/ApplicationSearch to AuthProviderConfig Summary: Ref T1536. Adds a list controller and ApplicationSearch integration for listing providers. Test Plan: {F46308} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6198
2013-06-17 19:50:43 +02:00
'PhabricatorAuthProviderConfigController' => 'PhabricatorAuthController',
Very rough edit workflow for AuthProvider configuration Summary: Ref T1536. Many rough / broken edges, but adds the rough skeleton of the provider edit workflow. Test Plan: {F46333} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6200
2013-06-17 19:52:38 +02:00
'PhabricatorAuthProviderConfigEditor' => 'PhabricatorApplicationTransactionEditor',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add storage for Auth configuration in preparation for moving it into a web interface Summary: Ref T1536. Currently, we have about 40 auth-related configuration options. This is already roughly 20% of our config, and we want to add more providers. Additionally, we want to turn some of these auth options into multi-auth options (e.g., allow multiple Phabricator OAuth installs, or, theoretically multiple LDAP servers). I'm going to move this into a separate "Auth" tool with a minimal CLI (`bin/auth`) interface and a more full web interface. Roughly: - Administrators will use the app to manage authentication providers. - The `bin/auth` CLI will provide a safety hatch if you lock yourself out by disabling all usable providers somehow. - We'll migrate existing configuration into the app and remove it. General goals: - Make it much easier to configure authentication by providing an interface for it. - Make it easier to configure everything else by reducing the total number of available options. Test Plan: Ran storage upgrade. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6196
2013-06-17 19:48:41 +02:00
'PhabricatorAuthProviderConfigTransaction' => 'PhabricatorApplicationTransaction',
Add PhabricatorAuthProviderConfigQuery Summary: Ref T1536. See D6196. Code not called yet. Test Plan: Static checks only. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6197
2013-06-17 19:49:18 +02:00
'PhabricatorAuthProviderConfigTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
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',
OAuth - add a little notes section for admins to remember details about external accounts Summary: Fixes T4755. This also includes putting in a note that Google might ToS you to use the Google+ API. Lots of code here as there was some repeated stuff between OAuth1 and OAuth2 so I made a base OAuth with less-base OAuth1 and OAuth2 inheriting from it. The JIRA provider remains an independent mess and didn't get the notes field thing. Test Plan: looked at providers and read pretty instructions. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4755 Differential Revision: https://secure.phabricator.com/D8726
2014-04-09 20:09:50 +02:00
'PhabricatorAuthProviderOAuth1' => 'PhabricatorAuthProviderOAuth',
Add JIRA as an authentication provider Summary: Ref T3687. Depends on D6867. This allows login/registration through JIRA. The notable difference between this and other providers is that we need to do configuration in two stages, since we need to generate and save a public/private keypair before we can give the user configuration instructions, which takes several seconds and can't change once we've told them to do it. To this effect, the edit form renders two separate stages, a "setup" stage and a "configure" stage. In the setup stage the user identifies the install and provides the URL. They hit save, we generate a keypair, and take them to the configure stage. In the configure stage, they're walked through setting up all the keys. This ends up feeling a touch rough, but overall pretty reasonable, and we haven't lost much generality. Test Plan: {F57059} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6868
2013-09-03 14:53:21 +02:00
'PhabricatorAuthProviderOAuth1JIRA' => 'PhabricatorAuthProviderOAuth1',
Add Twitter as an authentication provider Summary: Ref T3687. Depends on D6864. Implements the `OAuth1` provider in Phabricator (which is mostly similar to the OAuth2 provider, but doesn't share quite enough code to actually extend a common base class, I think) and Twitter as a concrete subclass. Test Plan: Created a Twitter provider. Registered, logged in, linked, refreshed account link. {F57054} {F57056} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3687 Differential Revision: https://secure.phabricator.com/D6865
2013-09-03 14:53:08 +02:00
'PhabricatorAuthProviderOAuth1Twitter' => 'PhabricatorAuthProviderOAuth1',
OAuth - add a little notes section for admins to remember details about external accounts Summary: Fixes T4755. This also includes putting in a note that Google might ToS you to use the Google+ API. Lots of code here as there was some repeated stuff between OAuth1 and OAuth2 so I made a base OAuth with less-base OAuth1 and OAuth2 inheriting from it. The JIRA provider remains an independent mess and didn't get the notes field thing. Test Plan: looked at providers and read pretty instructions. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4755 Differential Revision: https://secure.phabricator.com/D8726
2014-04-09 20:09:50 +02:00
'PhabricatorAuthProviderOAuth2' => 'PhabricatorAuthProviderOAuth',
'PhabricatorAuthProviderOAuthAmazon' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthAsana' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthDisqus' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthFacebook' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthGitHub' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthGoogle' => 'PhabricatorAuthProviderOAuth2',
'PhabricatorAuthProviderOAuthTwitch' => 'PhabricatorAuthProviderOAuth2',
WordPress.com OAuth2 plugin Summary: This plugin provides an OAuth authentication provider to authenticate users using WordPress.com Connect. This diff corresponds to github pull request https://github.com/facebook/phabricator/pull/593/ and had its libphutil counterpart reviewed in D9004. Test Plan: Configured WordPress.com as an authentication provider, saw it show up on the login screen, registered a new account, got expected defaults for my username/name/email/profile picture. Reviewers: chad, #blessed_reviewers, epriestley Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9019
2014-05-08 23:23:12 +02:00
'PhabricatorAuthProviderOAuthWordPress' => 'PhabricatorAuthProviderOAuth2',
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',
Add Persona auth provider Summary: Ref T3958. Adds a provider for Mozilla's Persona auth. Test Plan: - Created a Persona provider. - Registered a new account with Persona. - Logged in with Persona. - Linked an account with Persona. - Dissolved an account link with Persona. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3958 Differential Revision: https://secure.phabricator.com/D7313
2013-10-14 23:34:57 +02:00
'PhabricatorAuthProviderPersona' => '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',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSession' =>
array(
0 => 'PhabricatorAuthDAO',
1 => 'PhabricatorPolicyInterface',
),
Separate session management from PhabricatorUser Summary: Ref T4310. Ref T3720. Session operations are currently part of PhabricatorUser. This is more tightly coupled than needbe, and makes it difficult to establish login sessions for non-users. Move all the session management code to a `SessionEngine`. Test Plan: - Viewed sessions. - Regenerated Conduit certificate. - Verified Conduit sessions were destroyed. - Logged out. - Logged in. - Ran conduit commands. - Viewed sessions again. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7962
2014-01-14 22:22:27 +01:00
'PhabricatorAuthSessionEngine' => 'Phobject',
Expire and garbage collect unused sessions Summary: Ref T3720. Ref T4310. Currently, we limit the maximum number of concurrent sessions of each type. This is primarily because sessions predate garbage collection and we had no way to prevent the session table from growing fairly quickly and without bound unless we did this. Now that we have GC (and it's modular!) we can just expire unused sessions after a while and throw them away: - Add a `sessionExpires` column to the table, with a key. - Add a GC for old sessions. - When we establish a session, set `sessionExpires` to the current time plus the session TTL. - When a user uses a session and has used up more than 20% of the time on it, extend the session. In addition to this, we could also rotate sessions, but I think that provides very little value. If we do want to implement it, we should hold it until after T3720 / T4310. Test Plan: - Ran schema changes. - Looked at database. - Tested GC: - Started GC. - Set expires on one row to the past. - Restarted GC. - Verified GC nuked the session. - Logged in. - Logged out. - Ran Conduit method. - Tested refresh: - Set threshold to 0.0001% instead of 20%. - Loaded page. - Saw a session extension ever few page loads. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4310, T3720 Differential Revision: https://secure.phabricator.com/D7976
2014-01-15 22:56:16 +01:00
'PhabricatorAuthSessionGarbageCollector' => 'PhabricatorGarbageCollector',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorAuthSessionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Add "temporary tokens" to auth, for SMS codes, TOTP codes, reset codes, etc Summary: Ref T4398. We have several auth-related systems which require (or are improved by) the ability to hand out one-time codes which expire after a short period of time. In particular, these are: - SMS multi-factor: we need to be able to hand out one-time codes for this in order to prove the user has the phone. - Password reset emails: we use a time-based rotating token right now, but we could improve this with a one-time token, so once you reset your password the link is dead. - TOTP auth: we don't need to verify/invalidate keys, but can improve security by doing so. This adds a generic one-time code storage table, and strengthens the TOTP enrollment process by using it. Specifically, you can no longer edit the enrollment form (the one with a QR code) to force your own key as the TOTP key: only keys Phabricator generated are accepted. This has no practical security impact, but generally helps raise the barrier potential attackers face. Followup changes will use this for reset emails, then implement SMS multi-factor. Test Plan: - Enrolled in TOTP multi-factor auth. - Submitted an error in the form, saw the same key presented. - Edited the form with web tools to provide a different key, saw it reject and the server generate an alternate. - Change the expiration to 5 seconds instead of 1 hour, submitted the form over and over again, saw it cycle the key after 5 seconds. - Looked at the database and saw the tokens I expected. - Ran the GC and saw all the 5-second expiry tokens get cleaned up. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D9217
2014-05-20 20:43:45 +02:00
'PhabricatorAuthTemporaryToken' =>
array(
0 => 'PhabricatorAuthDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorAuthTemporaryTokenGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorAuthTemporaryTokenQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Allow users to terminate login sessions Summary: This is partly a good feature, and partly should reduce false positives on HackerOne reporting things vaguely related to this. Allow a user to terminate login sessions from the settings panel. Test Plan: - Terminated a session. - Terminated all sessions. - Tried to terminate all sessions again. - Logged in with two browsers, terminated the other browser's session, reloaded, got kicked out. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8556
2014-03-17 23:02:01 +01:00
'PhabricatorAuthTerminateSessionController' => 'PhabricatorAuthController',
Rate limit multi-factor actions Summary: Ref T4398. Prevent users from brute forcing multi-factor auth by rate limiting attempts. This slightly refines the rate limiting to allow callers to check for a rate limit without adding points, and gives users credit for successfully completing an auth workflow. Test Plan: Tried to enter hisec with bad credentials 11 times in a row, got rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8911
2014-04-30 23:30:31 +02:00
'PhabricatorAuthTryFactorAction' => 'PhabricatorSystemAction',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorAuthUnlinkController' => 'PhabricatorAuthController',
Implement new auth login flow and login validation controller Summary: Ref T1536. None of this code is reachable. Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly). Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 19:15:33 +02:00
'PhabricatorAuthValidateController' => 'PhabricatorAuthController',
First go at Authentication config options. Test Plan: Looked at them in the web UI. Reviewers: epriestley, chad, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4355
2013-01-07 21:48:39 +01:00
'PhabricatorAuthenticationConfigOptions' => 'PhabricatorApplicationConfigOptions',
Make it much easier to add one-off event listeners Summary: Ref T4657. Right now, you have to muck with `events.listeners` to install listeners. Instead, automatically install all subclasses of AutoEventListener. Primarily, this makes it easier to resolve requests with "drop this file in `src/extensions/`, no warranty", which seems to have worked well so far in resolving things like custom remarkup rules, etc. Test Plan: - Added such a listener, had it autoregister. - Clicked around and saw the effects of normal listeners. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4657 Differential Revision: https://secure.phabricator.com/D9262
2014-05-23 00:19:28 +02:00
'PhabricatorAutoEventListener' => 'PhabricatorEventListener',
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',
Implement bcrypt hasher, transparent login upgrade, and explicit upgrade for passwords Summary: Ref T4443. - Add a `password_hash()`-based bcrypt hasher if `password_hash()` is available. - When a user logs in using a password, upgrade their password to the strongest available hash format. - On the password settings page: - Warn the user if their password uses any algorithm other than the strongest one. - Show the algorithm the password uses. - Show the best available algorithm. Test Plan: As an md5 user, viewed password settings page and saw a warning. Logged out. Logged in, got upgraded, no more warning. Changed password, verified database rehash. Logged out, logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8270
2014-02-18 20:03:56 +01:00
'PhabricatorBcryptPasswordHasher' => 'PhabricatorPasswordHasher',
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',
'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',
Fix full width form layouts Summary: Fixes T3473, mostly reverts previous changes to clean up required field text, will have to redesign that in general for responsiveness. Test Plan: use logout form, use new conpherence form Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3473 Differential Revision: https://secure.phabricator.com/D6371
2013-07-04 05:24:28 +02:00
'PhabricatorBusyExample' => 'PhabricatorUIExample',
Add a generic multistep Markup cache Summary: The immediate issue this addresses is T1366, adding a rendering cache to Phriction. For wiki pages with code blocks especially, rerendering them each time is expensive. The broader issue is that out markup caches aren't very good right now. They have three major problems: **Problem 1: the data is stored in the wrong place.** We currently store remarkup caches on objects. This means we're always loading it and passing it around even when we don't need it, can't genericize cache management code (e.g., have one simple script to drop/GC caches), need to update authoritative rows to clear caches, and can't genericize rendering code since each object is different. To solve this, I created a dedicated cache database that I plan to move all markup caches to use. **Problem 2: time-variant rules break when cached.** Some rules like `**bold**` are time-invariant and always produce the same output, but some rules like `{Tnnn}` and `@username` are variant and may render differently (because a task was closed or a user is on vacation). Currently, we cache the raw output, so these time-variant rules get locked at whatever values they had when they were first rendered. This is the main reason Phriction doesn't have a cache right now -- I wanted `{Tnnn}` rules to reflect open/closed tasks. To solve this, I split markup into a "preprocessing" phase (which does all the parsing and evaluates all time-invariant rules) and a "postprocessing" phase (which evaluates time-variant rules only). The preprocessing phase is most of the expense (and, notably, includes syntax highlighting) so this is nearly as good as caching the final output. I did most of the work here in D737 / D738, but we never moved to use it in Phabricator -- we currently just do the two operations serially in all cases. This diff splits them apart and caches the output of preprocessing only, so we benefit from caching but also get accurate time-variant rendering. **Problem 3: cache access isn't batched/pipelined optimally.** When we're rendering a list of markup blocks, we should be able to batch datafetching better than we do. D738 helped with this (fetching is batched within a single hunk of markup) and this improves batching on cache access. We could still do better here, but this is at least a step forward. Also fixes a bug with generating a link in the Phriction history interface ($uri gets clobbered). I'm using PHP serialization instead of JSON serialization because Remarkup does some stuff with non-ascii characters that might not survive JSON. Test Plan: - Created a Phriction document and verified that previews don't go to cache (no rows appear in the cache table). - Verified that published documents come out of cache. - Verified that caches generate/regenerate correctly, time-variant rules render properly and old documents hit the right caches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1366 Differential Revision: https://secure.phabricator.com/D2945
2012-07-10 00:20:56 +02:00
'PhabricatorCacheDAO' => 'PhabricatorLiskDAO',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheGeneralGarbageCollector' => 'PhabricatorGarbageCollector',
Make all bin/* scripts locate their workflows dynamically Summary: Ref T2015. Not directly related to Drydock, but I bumped into this. All these scripts currently enumerate their workflows explicitly. Instead, use `PhutilSymbolLoader` to automatically discover workflows. This reduces code duplication and errors (see all the bad `extends` this diff fixes) and lets third parties add new workflows (not clearly valuable?). Test Plan: Ran `bin/x help` for each modified script. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7840
2013-12-27 22:15:48 +01:00
'PhabricatorCacheManagementPurgeWorkflow' => 'PhabricatorCacheManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorCacheManagementWorkflow' => 'PhabricatorManagementWorkflow',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorCacheMarkupGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorCacheTTLGarbageCollector' => 'PhabricatorGarbageCollector',
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',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
'PhabricatorCalendarEvent' =>
array(
0 => 'PhabricatorCalendarDAO',
1 => 'PhabricatorPolicyInterface',
),
Rename "status" to "event" in most URIs / classes / etc Summary: Ref T4375. This doesn't get everything (I figure I'll clean up the actual UI strings when I touch the UIs) but should get the bulk of the URIs and class names and stuff. Test Plan: Clicked every calendar-related link I could find/grep, they all still seem to work. URIs now say "event". Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8147
2014-02-06 19:10:07 +01:00
'PhabricatorCalendarEventDeleteController' => 'PhabricatorCalendarController',
'PhabricatorCalendarEventEditController' => 'PhabricatorCalendarController',
Rename PhabricatorUserStatus to PhabricatorCalendarEvent Summary: Ref T4375. We never join this table, so this is a pretty straight find/replace. Test Plan: Browsed around Calendar, verified that nothing seemed broken. Saw my red dot in other apps. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8145
2014-02-06 19:07:29 +01:00
'PhabricatorCalendarEventInvalidEpochException' => 'Exception',
Move rendering to SearchEngine for Calendar Summary: Ref T4986. This one needs `getApplicationURI()` so make it a little beefier to deal with that. (It would be vaguely nice to somehow share the handle and application stuff between Controllers and Engine classes like this, but I don't immediately see a clean way to do it without traits. Not a big deal, in any case.) Test Plan: - Viewed Calendar. - Made a Calendar panel. - Viewed feed. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9012
2014-05-08 18:18:02 +02:00
'PhabricatorCalendarEventListController' => 'PhabricatorCalendarController',
Use a modern query object to query Calendar events Summary: Ref T4375. Calendar uses oldschool `loadOneWhere()` calls. Make CalendarEvent policy-aware, do the edit/delete policy checks through the policy framework, and use modern query infrastructure. Test Plan: - Viewed calendar; - created, edited, deleted event; - viewed calendar tab in Conpherence. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8146
2014-02-06 19:07:42 +01:00
'PhabricatorCalendarEventQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in the calendar event list view Summary: Ref T4375. Basic ApplicationSearch integration to power this more flexibly. Test Plan: {F108762} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8148
2014-02-06 19:10:18 +01:00
'PhabricatorCalendarEventSearchEngine' => 'PhabricatorApplicationSearchEngine',
Differential - add DifferentialDraft to track whether revisions have draft feedback or not Summary: ...do it somewhat generically, so we could fairly easily add this to other applications. Fixes T3496. I got a wee bit lazy and decided not to migrate existing drafts. My excuses aside from laziness are doing it this way will let us see if anyone complains, we can always do a migration later if people do complain, and there's likely to be a lot of garbage data for older / bigger installs, and the migration didn't seem worth itgiven it would also likely be expensive in these cases. Test Plan: made a draft inline comment on DX and observed DX had a note icon on Differential home page. made a draft comment on DX and observed DX had a note icon on Differential home page. deleted a draft inline comment and noted icon disappeared from Differential homepage. Submitted a draft comment + inline comment and noted icon disappeared. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3496 Differential Revision: https://secure.phabricator.com/D8275
2014-02-19 01:25:16 +01:00
'PhabricatorCalendarEventViewController' => 'PhabricatorCalendarController',
Display holidays Summary: We will need it for two purposes: - Status tool. - Nagging tool - @aran suggested using "3 business days" and I don't want it to fall on New Year's Eve or such. I don't plan working on any interface for editing this as this kind of data should be always imported. Test Plan: `bin/storage upgrade` `scripts/calendar/import_us_holidays.php` /calendar/ Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2375
2012-05-03 09:21:47 +02:00
'PhabricatorCalendarHoliday' => 'PhabricatorCalendarDAO',
Implement getNthBusinessDay() Summary: I will need it for nagging tool. Test Plan: None yet. Please suggest me how to create a testing database (I need to insert some data in the table). I guess that it is now possible? There is also probably some bug in `arc unit` - `setEnvConfig()` is not called before `getEnvConfig()` resulting in fatal error. Reviewers: epriestley Reviewed By: epriestley CC: aran, Koolvin Differential Revision: https://secure.phabricator.com/D2376
2012-05-03 21:16:09 +02:00
'PhabricatorCalendarHolidayTestCase' => 'PhabricatorTestCase',
Assign PHIDs to calendar events Summary: Ref T4375. We're going to need these for a bunch of infrastructure to work. Test Plan: Ran migrations, checked DB, used `phid.query`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4375 Differential Revision: https://secure.phabricator.com/D8151
2014-02-06 19:10:43 +01:00
'PhabricatorCalendarPHIDTypeEvent' => 'PhabricatorPHIDType',
Make "My Events" default on Calendar Summary: Moves Browse to "View All" and makes "My Events" the default on Calendar. Test Plan: Browse both pages. Reviewers: btrahan, epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D8397
2014-03-05 17:24:45 +01:00
'PhabricatorCalendarViewController' => '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',
Add unit tests for Git change parsers Summary: Ref T4327. Adds some basic tests to the Git parser for a set of common operations (add, change, move, copy, directory, symlink, propchange). Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D8012
2014-01-20 22:14:04 +01:00
'PhabricatorChangeParserTestCase' => 'PhabricatorWorkingCopyTestCase',
Minor, formalize changeset response class.
2012-03-13 05:39:05 +01:00
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
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',
Add CustomField to Diffusion and add a "branches" field Summary: Ref T4588. Request from @zeeg. Adds a "BRANCHES" field to commit emails, so the branches the commit appears on are shown. I've implemented this with CustomField, but in a very light way. Test Plan: Used `scripts/repository/reparse.php --herald` to generate mail, got a BRANCHES section where applicable. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley, zeeg Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8501
2014-03-12 19:30:33 +01:00
'PhabricatorCommitBranchesField' => 'PhabricatorCommitCustomField',
'PhabricatorCommitCustomField' => 'PhabricatorCustomField',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
'PhabricatorCommitSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add a "tags" field to Diffusion commit Summary: - Fixes T4588. - See D8501. - Adds a "Tags" field for Herald commit emails. - Fixes a bug in `tagsquery` when filtering by commit name. - Make `tagsquery` just return nothing instead of fataling against Mercurial/Subversion. Test Plan: Used `bin/repository/reparse.php --herald` to exercise this code. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8502
2014-03-12 19:30:52 +01:00
'PhabricatorCommitTagsField' => 'PhabricatorCommitCustomField',
Add a common password blacklist Summary: Fixes T4143. This mitigates the "use a botnet to slowly try to login to every user account using the passwords '1234', 'password', 'asdfasdf', ..." attack, like the one that hit GitHub. (I also donated some money to Openwall as a thanks for compiling this wordlist.) Test Plan: - Tried to register with a weak password; registered with a strong password. - Tried to set VCS password to a weak password; set VCS password to a strong password. - Tried to change password to a weak password; changed password to a strong password. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T4143 Differential Revision: https://secure.phabricator.com/D8048
2014-01-23 23:01:18 +01:00
'PhabricatorCommonPasswords' => 'Phobject',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
"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',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorConduitListController' => 'PhabricatorConduitController',
Conduit server-side basics.
2011-01-24 18:00:29 +01:00
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
Mostly modernize Conduit logs Summary: - Add GC support to conduit logs. - Add Query support to conduit logs. - Record the actual user PHID. - Show client name. - Support querying by specific method, so I can link to this from a setup issue. @wez, this migration may not be fast. It took about 8 seconds for me to migrate 800,000 rows in the `conduit_methodcalllog` table. This adds a GC which should keep the table at a more manageable size in the future. You can safely delete all data older than 30 days from this table, although you should do it by `id` instead of `dateCreated` since there's no key on `dateCreated` until this patch. Test Plan: - Ran GC. - Looked at log UI. - Ran Conduit methods. Reviewers: btrahan Reviewed By: btrahan CC: wez, aran Differential Revision: https://secure.phabricator.com/D6332
2013-07-01 21:37:34 +02:00
'PhabricatorConduitLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorConduitMethodCallLog' =>
array(
0 => 'PhabricatorConduitDAO',
1 => 'PhabricatorPolicyInterface',
),
Modernize most Conduit console interfaces Summary: Ref T603. Ref T2625. Long chain of "doing the right thing" here: I want to clean this up, so I can clean up the Conduit logs, so I can add a setup issue for deprecated method calls, so I can remove deprecated methods, so I can get rid of `DifferentialRevisionListData`, so I can make Differntial policy-aware. Adds modern infrastructure and UI to all of the Conduit interfaces (except only partially for the logs, that will be the next diff). Test Plan: {F48201} {F48202} {F48203} {F48204} {F48206} This will get further updates in the next diff: {F48205} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6331
2013-07-01 21:36:34 +02:00
'PhabricatorConduitMethodQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorConduitSearchEngine' => 'PhabricatorApplicationSearchEngine',
"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',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigEntry' =>
array(
0 => 'PhabricatorConfigEntryDAO',
1 => 'PhabricatorPolicyInterface',
),
Start of a config web interface. Summary: This is somewhat clowny, particularly in how it handles JSON encode/decode, but I've commented why I did things the way I did. The goal is to store minified JSON but show pretty-printed JSON where possible, to the user editing it. Test Plan: * Went to /config/ and saw a list of keys from the `default` config. * Clicked on one of them, submitted the default value successfully. * Changed the value to invalid JSON and got a decent error. * Changed the value to valid JSON and checked the DB to confirm it saved. * Confirmed the DB values were minified. * Confirmed the user-facing values were pretty-printed where they could be. * Confirmed that PHIDs were getting assigned properly and that isDeleted properly defaulted to false/0. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2246 Differential Revision: https://secure.phabricator.com/D4290
2012-12-28 00:20:09 +01:00
'PhabricatorConfigEntryDAO' => 'PhabricatorLiskDAO',
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigEntryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Formalize configuration sources and source stacks Summary: Currently, we have a configuration stack for unit tests, but they're built in to `PhabricatorEnv`. Pull them out and formalize them, so we can add more configuration sources (e.g., database). Test Plan: Ran unit tests, web requests, scripts. This code had fairly good existing test coverage. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T2223, T2221 Differential Revision: https://secure.phabricator.com/D4284
2012-12-25 15:44:29 +01:00
'PhabricatorConfigFileSource' => 'PhabricatorConfigProxySource',
Begin moving Phabricator configuration into PHP Summary: Ref T2255. Ref T2221. Lay the groundwork to move configuration into PHP, so we can show descriptions in the web UI, do typechecking, disable application options when an application is uninstalled, etc. Test Plan: {F28421} {F28420} {F28422} Reviewers: codeblock, btrahan, vrana Reviewed By: codeblock CC: aran Maniphest Tasks: T2221, T2255 Differential Revision: https://secure.phabricator.com/D4306
2012-12-31 00:36:06 +01:00
'PhabricatorConfigGroupController' => 'PhabricatorConfigController',
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',
Make Maniphest task statuses user configurable Summary: Fixes T1812. Moves the internal configuration into public space and documents it. Test Plan: - Tried to set it to some invalid stuff. - Set it to various valid things. - Browsed around, changed statuses, filtered statuses, viewed statuses, merged duplictes, examined transaction record, created tasks. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T1812 Differential Revision: https://secure.phabricator.com/D8585
2014-03-25 22:05:36 +01:00
'PhabricatorConfigJSONOptionType' => 'PhabricatorConfigOptionType',
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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorConfigManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
),
Convert config to application PHIDs Summary: Ref T2715. Test Plan: Used `phid.query` to load config entries. Edited config entries. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6520
2013-07-22 00:04:21 +02:00
'PhabricatorConfigPHIDTypeConfig' => 'PhabricatorPHIDType',
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',
Move Conpherence Threads to new phid stuff Summary: Ref T2715. Test Plan: loaded conpherence, loaded a different thread, made a conpherence. also phid.query Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6577
2013-07-26 21:07:47 +02:00
'PhabricatorConpherencePHIDTypeThread' => 'PhabricatorPHIDType',
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',
Consolidate use of magical cookie name strings Summary: Ref T4339. We have more magical cookie names than we should, move them all to a central location. Test Plan: Registered, logged in, linked account, logged out. See inlines. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4339 Differential Revision: https://secure.phabricator.com/D8041
2014-01-23 23:01:35 +01:00
'PhabricatorCookies' => 'Phobject',
Add "Core" config, with complex validation Summary: This is more or less a copy of the validation which lives in `webroot/index.php` right now, but I don't want to wipe that out just yet because there's no way for normal users to see this new validation. Test Plan: Tried to set "phabricator.base-uri" to crazy nonsense, was harshly rebuffed. Reviewers: codeblock, btrahan Reviewed By: codeblock CC: aran Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4316
2013-01-02 03:22:48 +01:00
'PhabricatorCoreConfigOptions' => 'PhabricatorApplicationConfigOptions',
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',
),
Add application and object level policy controls to Countdown Summary: Ref T603. Give countdowns proper UI-level policy controls, and an application-level default policy. Put policy information in the header. Test Plan: - Adjusted default policy. - Created new countdowns. - Edited countdowns. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7322
2013-10-16 19:36:08 +02:00
'PhabricatorCountdownCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Countdown Summary: Addon that allows you to create a live countdown page to some event. Here is the ticket that this code is based on https://secure.phabricator.com/T36 Test Plan: Tested by manually setting dates in the timer.js file and checking if they made sense. I'm not sure if it works across different timezones though. Reviewers: epriestley CC: Differential Revision: 436
2011-06-13 01:06:17 +02:00
'PhabricatorCountdownController' => 'PhabricatorController',
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
Use application PHIDs in countdown Summary: Ref T2715. Swap countdown to application PHIDs. Test Plan: Used `phid.lookup`; `phid.query`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6532
2013-07-22 23:42:25 +02:00
'PhabricatorCountdownPHIDTypeCountdown' => 'PhabricatorPHIDType',
'PhabricatorCountdownQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Modernize Countdown somewhat Summary: Far from perfect, but better? Test Plan: {F51153} {F51154} {F51155} Reviewers: btrahan, chad Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6533
2013-07-23 15:16:19 +02:00
'PhabricatorCountdownSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorCountdownView' => 'AphrontTagView',
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',
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',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldList' => 'Phobject',
Modularize parser for "Closes task X as Y" Summary: Ref T3886. Ref T3872. Ref T1812. We have several parsers which look for textual references to other objects, like: Closes Tx. Depends on Dy. Reverts Dz. Currently, these are pretty hard coded, don't get all the edge cases right, and don't generalize well. They're also implemented in the middle of Differential's field code. So I want to: - Share more code so that, e.g., "Tx, Ty" always works (only some rules support it right now); - fix bugs in the parser, like T3872; - make this a modular, extensible process which runs against custom fields, not a builtin part of fields; - make the internals more flexible to accommodate custom stuff like T1812. This implements the "Verbs optional-noun Object, Optional Other Objects optional-as-something." grammar in a general way so subclasses can just plug in their keywords. Runtime code doesn't touch this yet. Test Plan: Ran unit tests. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3872, T1812, T3886 Differential Revision: https://secure.phabricator.com/D8261
2014-02-18 00:53:47 +01:00
'PhabricatorCustomFieldMonogramParser' => 'Phobject',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorCustomFieldNotAttachedException' => 'Exception',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorCustomFieldNotProxyException' => 'Exception',
Begin generalizing custom fields Summary: Ref T1703. We have currently have two custom field implementations (Maniphest, Differential) and are about to add a third (User, see D6122). I'd like to generalize custom fields before doing a third implementation, so we don't back ourselves into the ApplicationTransactions corner we have with Maniphest/Differential/Audit. For the most part, the existing custom fields work well and can be directly generalized. There are three specific things I want to improve, though: - Integration with ApplicationSearch: Custom fields aren't indexable. ApplicationSearch is now online and seems stable and good. D5278 provides a template for a backend which can integrate with ApplicationSearch, and ApplicationSearch solves many of the other UI problems implied by exposing custom fields into search (principally, giant pages full of query fields). Generally, I want to provide stronger builtin integration between custom fields and ApplicationSearch. - Integration with ApplicationTransactions: Likewise, custom fields should support more native integrations with ApplicationTransactions, which are also online and seem stable and well designed. - Selection and sorting: Selecting and sorting custom fields is a huge mess right now. I want to move this into config now that we have the UI to support it, and move away from requiring users to subclass a ton of stuff just to add a field. For ApplicationSearch, I've adopted and generalized D5278. For ApplicationTransactions, I haven't made any specific affordances yet. For selection and sorting, I've partially implemented config-based selection and sorting. It will work like this: - We add a new configuration value, like `differential.fields`. In the UI, this is a draggable list of supported fields. Fields can be reordered, and most fields can be disabled. - We load every avialable field to populate this list. New fields will appear at the bottom. - There are two downsides to this approach: - If we add fields in the upstream at a later date, they will appear at the end of the list if an install has customized list order or disabled fields, even if we insert them elsewhere in the upstream. - If we reorder fields in the upstream, the reordering will not be reflected in install which have customized the order/availability. - I think these are both acceptable costs. We only incur them if an admin edits this config, which implies they'll know how to fix it if they want to. - We can fix both of these problems with a straightforward configuration migration if we want to bother. - There are numerous upsides to this approach: - We can delete a bunch of code and replace it with simple configuration. - In general, we don't need the "selector" classes anymore. - Users can enable available-but-disabled fields with one click. - Users can add fields by putting their implementations in `src/extensions/` with zero subclassing or libphutil stuff. - Generally, it's super easy for users to understand. This doesn't actually do anything yet and will probably see some adjustments before anything starts running it. Test Plan: Static checks only, this code isn't reachable yet. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6147
2013-06-06 23:52:40 +02:00
'PhabricatorCustomFieldNumericIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
'PhabricatorCustomFieldStorage' => 'PhabricatorLiskDAO',
'PhabricatorCustomFieldStringIndexStorage' => 'PhabricatorCustomFieldIndexStorage',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorDaemonEventListener' => 'PhabricatorEventListener',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonLog' =>
array(
0 => 'PhabricatorDaemonDAO',
1 => 'PhabricatorPolicyInterface',
),
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
Allow long daemon log messages to be expanded Summary: Ref T3557. We summarize long messages, but don't let you see the entire message. This is occasionally inconvenient, and I'm planning to add more prefix junk to some messages for T2569. Provide a link you can click to see the full message. This isn't javascripted because a ton of these can make the page ridiculously enormous and it seems unlikely you'd care much about all of them. Test Plan: {F51261} {F51262} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6546
2013-07-23 21:30:58 +02:00
'PhabricatorDaemonLogEventViewController' => 'PhabricatorDaemonController',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonLogEventsView' => 'AphrontView',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonLogGarbageCollector' => 'PhabricatorGarbageCollector',
Improve web tools for viewing daemons Summary: - Provides an "all daemons" view to look at more than the first 15 daemons. - Provides a "combined log" view with a large page size, to quickly look at the log across all the daemons, making it easier to find issues when you have a bunch of the same daemon and only one is having issues. - When viewing the web console on the same host as a daemon, show whether it's running or not. Test Plan: Clicked the various daemon log interfaces. Reviewed By: aran Reviewers: jungejason, tuomaspelkonen, aran CC: aran Differential Revision: 215
2011-05-03 02:05:22 +02:00
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
'PhabricatorDaemonLogListView' => 'AphrontView',
Use a real Query class to load daemon information Summary: Ref T3557. This stuff does a bunch of nonsense in the View right now. Instead, do it in a real Query class. Fixes a long-standing bug which prevented "all daemons" from showing more than 3 days' worth of data. Test Plan: Viewed `/daemon/`, viewed "All Daemons". Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6544
2013-07-23 21:11:34 +02:00
'PhabricatorDaemonLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Diffusion/phd/console improvements.
2011-03-15 21:38:14 +01:00
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementDebugWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementLaunchWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementListWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Add `bin/phd log <id>` to dump all logs to the CLI Summary: Ref T3557. Make it easier to access full daemon logs from the CLI. Test Plan: {F51265} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3557 Differential Revision: https://secure.phabricator.com/D6547
2013-07-23 21:48:45 +02:00
'PhabricatorDaemonManagementLogWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Modernize architecture of `phd` Summary: Ref T1670. Mostly, use PhutilArgumentParser. This breaks up the mismash of functional stuff and PhabriatorDaemonControl into proper argumentparser Workflows. There are no functional changes, except that I removed the "pingConduit()" call prior to starting daemons, because I intend to remove all Conduit integration. Test Plan: - Ran `phd list`. - Ran `phd status` (running daemons). - Ran `phd status` (no running daemons). - Ran `phd stop <pid>` (dead task). - Ran `phd stop <pid>` (live task). - Ran `phd stop zebra` (invalid PID). - Ran `phd stop 1` (bad PID). - Ran `phd stop`. - Ran `phd debug zebra` (no match). - Ran `phd debug e` (ambiguous). - Ran `phd debug task`. - Ran `phd launch task`. - Ran `phd launch 0 task` (invalid arg). - Ran `phd launch 2 task`. - Ran `phd help`. - Ran `phd help list`. - Ran `phd start`. - Ran `phd restart`. - Looked at Repositories (daemon running). - Looked at Repositories (daemon not running). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1670 Differential Revision: https://secure.phabricator.com/D6490
2013-07-19 00:28:56 +02:00
'PhabricatorDaemonManagementRestartWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStartWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStatusWorkflow' => 'PhabricatorDaemonManagementWorkflow',
'PhabricatorDaemonManagementStopWorkflow' => 'PhabricatorDaemonManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorDaemonManagementWorkflow' => 'PhabricatorManagementWorkflow',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorDaemonTaskGarbageCollector' => 'PhabricatorGarbageCollector',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboard' =>
array(
0 => 'PhabricatorDashboardDAO',
1 => 'PhabricatorPolicyInterface',
),
Allow panels to appear on dashboards Summary: Ref T3583. Adds edges, query relationships, etc. Lots of debugging/temporary UI. My general intent here is to use edges to track where panels appear, and then put additional data on the dashboard itself to control layout, positioning, etc. Dashboards don't actually render yet so this is still pretty boring. Test Plan: {F149175} {F149176} {F149177} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8916
2014-04-30 23:28:55 +02:00
'PhabricatorDashboardAddPanelController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardController' => 'PhabricatorController',
Allow entire dashboards to be copied Summary: Further improve UX for dealing with policy rules on dashboards: - When in the "Manage" view of a dashboard you can not edit: - Don't show the panel management controls. - Show a notice that the board isn't editable, recommending you make a copy instead. - Add a "Copy Dashboard" action to create a copy which you //can// edit. Test Plan: Copied some dashboards. See screenshots. Reviewers: chad Reviewed By: chad Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D9508
2014-06-13 06:49:19 +02:00
'PhabricatorDashboardCopyController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardDAO' => 'PhabricatorLiskDAO',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardEditController' => 'PhabricatorDashboardController',
Move Dashboard and Panel edit history out of the way Summary: Fixes T5170, Create new page for dashboard history Test Plan: Open dashboard, manage dashboard, click on "View History". Dashboard history should appear. Panel history should appear on panel view page under panel. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T5170 Differential Revision: https://secure.phabricator.com/D9280
2014-05-24 21:29:27 +02:00
'PhabricatorDashboardHistoryController' => 'PhabricatorDashboardController',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardInstall' => 'PhabricatorDashboardDAO',
'PhabricatorDashboardInstallController' => 'PhabricatorDashboardController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorDashboardListController' => 'PhabricatorDashboardController',
Make the default view of dashboards be just the dashboard Summary: Fixes T4985, add manage page, change view page to show only panels. Arguably, PhabricatorDashboardArrangeController is no longer necessary. Also, still trying to figure out if I updated all flows that involve "arrange/{id}". Probably missed some. Also not sure of the Manage Dashboard icon. Please advise. Test Plan: Create dashboard, add panels, "view/{id}" should show just panels, Manage Dashboard should show timeline and edit links. Reviewers: #blessed_reviewers, epriestley, chad Reviewed By: #blessed_reviewers, epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4985 Differential Revision: https://secure.phabricator.com/D9258
2014-05-22 19:59:46 +02:00
'PhabricatorDashboardManageController' => 'PhabricatorDashboardController',
Dashboards - add layout mode to dashboards Summary: This gets us the ability to specify a "layout mode" and which column a panel should appear in at panel add time. Changing the layout mode from a multi column view to a single column view or vice versa will reset all panels to the left most column. You can also drag and drop where columns appear via the "arrange" mode. We also have a new dashboard create flow. Create dashboard -> arrange mode. (As opposed to view mode.) This could all possibly use massaging. Fixes T4996. Test Plan: made a dashboard with panels in multiple columns. verified correct widths for various layout modes re-arranged collumns like whoa. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4996 Differential Revision: https://secure.phabricator.com/D9031
2014-05-16 04:12:40 +02:00
'PhabricatorDashboardMovePanelController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPHIDTypeDashboard' => 'PhabricatorPHIDType',
'PhabricatorDashboardPHIDTypePanel' => 'PhabricatorPHIDType',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanel' =>
array(
0 => 'PhabricatorDashboardDAO',
1 => 'PhabricatorPolicyInterface',
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
2 => 'PhabricatorCustomFieldInterface',
),
'PhabricatorDashboardPanelCoreCustomField' =>
array(
0 => 'PhabricatorDashboardPanelCustomField',
1 => 'PhabricatorStandardCustomFieldInterface',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
),
Let dashboard panel types use customfield to manage editing Summary: Ref T3583. Use the same approach Harbormaster does to give panels cheap forms. Test Plan: {F149218} {F149219} {F149220} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8919
2014-04-30 23:29:41 +02:00
'PhabricatorDashboardPanelCustomField' => 'PhabricatorCustomField',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelEditController' => 'PhabricatorDashboardController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorDashboardPanelListController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Let dashboard panels render in a very basic way Summary: Ref T3583. This implements very primitive panel rendering on the panel detail page, and an ajaxable standalone view. Test Plan: {F149135} {F149136} {F149137} {F149138} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8913
2014-04-30 23:28:37 +02:00
'PhabricatorDashboardPanelRenderController' => 'PhabricatorDashboardController',
'PhabricatorDashboardPanelRenderingEngine' => 'Phobject',
Allow users to select QueryPanel search engines from a list Summary: Ref T4986. Instead of requiring users to know the name of an application search engine class, let them select from a list. Test Plan: Created a new panel. {F165468} Reviewers: chad Reviewed By: chad Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9500
2014-06-12 22:22:20 +02:00
'PhabricatorDashboardPanelSearchApplicationCustomField' => 'PhabricatorStandardCustomField',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardPanelSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorDashboardPanelTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorDashboardPanelTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelType' => 'Phobject',
Rough skeleton of a "Query" dashboard panel Summary: Ref T4986. This isn't pretty/usable yet (I need to move rendering out of ListController classes and into SearchEngine classes, I think) but does pull the correct results. Test Plan: {F151537} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9007
2014-05-07 23:56:30 +02:00
'PhabricatorDashboardPanelTypeQuery' => 'PhabricatorDashboardPanelType',
Add a "tabs" dashboard panel type Summary: Ref T4986. Allows you to create a dashboard panel out of dashboard panels. bwahaha Test Plan: {F155472} {F155473} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9141
2014-05-16 04:23:13 +02:00
'PhabricatorDashboardPanelTypeTabs' => 'PhabricatorDashboardPanelType',
Add dashboard panel types Summary: Ref T3583. These will be the primary class carrying panel implementations. Test Plan: {F149125} {F149126} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8912
2014-04-30 23:28:20 +02:00
'PhabricatorDashboardPanelTypeText' => 'PhabricatorDashboardPanelType',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardPanelViewController' => 'PhabricatorDashboardController',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Embed dashboard panels in comments Summary: Fixes T4983, Panel prefix 'W' should be recognized as a shortcut to a dashboard panel Test Plan: Open any comment input, type '{W1}', or other existing panel, preview should embed that panel. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T4983 Differential Revision: https://secure.phabricator.com/D9215
2014-05-20 19:53:27 +02:00
'PhabricatorDashboardRemarkupRule' => 'PhabricatorRemarkupRuleObject',
Dashboards - add remove functionality Summary: To get there, upgrade "headerless" to "headerMode". Add a new removepanel controller. Fixes T5084. Test Plan: removed some panels to much success Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5078, T5084 Differential Revision: https://secure.phabricator.com/D9156
2014-05-19 23:04:26 +02:00
'PhabricatorDashboardRemovePanelController' => 'PhabricatorDashboardController',
Give dashboards basic rendering and Ajax support Summary: Ref T3583. Let dashboards "render", sorta. Test Plan: {F149187} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8917
2014-04-30 23:29:14 +02:00
'PhabricatorDashboardRenderingEngine' => 'Phobject',
Add initial skeleton for Dashboard application Summary: Ref T3583. General idea here is: - Users will be able to create `DashboardPanel`s, which are things like the jump nav, or a minifeed, or recent assigned tasks, or recent tokens given, or whatever else. - The `DashboardPanel`s can be combined into `Dashboard`s, which select specific panels and arrange them in some layout (and maybe have a few other options eventually). - Then, you'll be able to set a specific `Dashboard` for your home page, and maybe for project home pages. But you can also use `Dashboard`s on their own if you just like dashboards. My plan is pretty much: - Put in basic infrastructure for dashboards (this diff). - Add basic create/edit (next few diffs). - Once dashboards sort of work, do the homepage integration. This diff does very little: you can't create dashboards or panels yet, and thus there are no dashboards to look at. This is all skeleton code, pretty much. IMPORTANT: We need an icon bwahahahahaha Test Plan: omg si purrfect {F106367} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8109
2014-01-30 20:43:24 +01:00
'PhabricatorDashboardSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorDashboardTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorDashboardTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Dashboards - add ability to install dashboard as home Summary: See title. Adds PhabricatorDashboardInstall data object which scopes installs to objectPHID + applicationClass. This is because we already have a collision for user home pages and user profiles. Assume only one dashboard per objectPHID + applicationClass though at the database level. Fixes T5076. Test Plan: From dashboard view, installed a dashboard - success! Went back to dashboard view and uninstalled it! Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5076 Differential Revision: https://secure.phabricator.com/D9206
2014-05-20 01:09:31 +02:00
'PhabricatorDashboardUninstallController' => 'PhabricatorDashboardController',
Add edit/view plumbing for dashboards and panels Summary: Ref T3583. This doesn't add any dashboard/panel-specific code beyond headers/titles/buttons/etc., but allows you to create and view dashboards and panel skeletons. Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3583 Differential Revision: https://secure.phabricator.com/D8131
2014-02-03 19:52:15 +01:00
'PhabricatorDashboardViewController' => 'PhabricatorDashboardController',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'PhabricatorDataNotAttachedException' => 'Exception',
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',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorDestructionEngine' => 'Phobject',
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',
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',
Modernize email verification page Summary: Fixes T3517. Moves the email verification page out of People and into Auth. Makes it look less awful. Test Plan: {F49636} {F49637} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3517 Differential Revision: https://secure.phabricator.com/D6425
2013-07-11 03:53:09 +02:00
'PhabricatorEmailVerificationController' => 'PhabricatorAuthController',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorEventListener' => 'PhutilEventListener',
Move event framework from Phabricator to libphutil Summary: Move event framework from Phabricator to libphutil so it can be used in other phutil projects, such as Arcanist. Test plan: Use along with path to libphutil, events should work as expected. Reviewers: epriestley Differential Revision: 1098
2011-11-10 02:23:33 +01:00
'PhabricatorEventType' => 'PhutilEventType',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorExampleEventListener' => 'PhabricatorEventListener',
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',
Clean up image loading for ExternalAccounts Summary: Ref T1536. This gets the single queries out of the View and builds a propery Query class for ExternalAccount. Test Plan: Linked/unlinked accounts, logged out, logged in. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6212
2013-06-17 21:14:00 +02:00
'PhabricatorExternalAccount' =>
array(
0 => 'PhabricatorUserDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorExternalAccountQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFactManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add a basic "fact" application Summary: Basic "Fact" application with some storage, part of a daemon, and a control binary. = Goals = The general idea is that we have various statistics we'd like to compute, like the frequency of image macros, reviewer responsiveness, task close rates, etc. Computing these on page load is expensive and messy. By building an ETL pipeline and running it in a daemon, we can precompute statistics and just pull them out of "stats" tables. One way to do this is just to completely hard-code everything, e.g. have a daemon that runs every hour which issues a big-ass query and dumps results into a table per-fact or per fact-group. But this has a bunch of drawbacks: adding new stuff to the pipeline is a pain, various fact aggregators can't share much code, updates are slow and expensive, we can never build generic graphs on top of it, etc. I'm hoping to build an ETL pipeline which is generic enough that we can use it for most things we're interested in without needing schema changes, and so that installs can use it also without needing schema changes, while still being specific enough that it's fast and we can build useful stuff on top of it. I'm not sure if this will actually work, but it would be cool if it does so I'm starting pretty generally and we'll see how far I get. I haven't built this exact sort of thing before so I might be way off. I'm basing the whole thing on analyzing entire objects, not analyzing changes to objects. So each part of the pipeline is handed an object and told "analyze this", not handed a change. It pretty much deletes all the old data about that thing and then writes new data. I think this is simpler to implement and understand, and it protects us from all sorts of weird issues where we end up with some kind of garbage in the DB and have to wipe the whole thing. = Facts = The general idea is that we extract "facts" out of objects, and then the various view interfaces just report those facts. This change has on type of fact, a "raw fact", which is directly derived from an object. These facts are concerete and relate specifically to the object they are derived from. Some examples of such facts might be: D123 has 9 comments. D123 uses macro "psyduck" 15 times. D123 adds 35 lines. D123 has 5 files. D123 has 1 object. D123 has 1 object of type "DREV". D123 was created at epoch timestamp 89812351235. D123 was accepted by @alincoln at epoch timestamp 8397981839. The fact storage looks like this: <factType, objectPHID, objectA, valueX, valueY, epoch> Currently, we supprot one optional secondary key (like a user PHID or macro PHID), two optional integer values, and an optional timestamp. We might add more later. Each fact type can use these fields if it wants. Some facts use them, others don't. For instance, this diff adds a "N:*" fact, which is just the count of total objects in the system. These facts just look like: <"N:*", "PHID-xxxx-yyyy", ...> ...where all other fields are ignored. But some of the more complex facts might look like: <"DREV:accept", "PHID-DREV-xxxx", "PHID-USER-yyyy", ..., ..., nnnn> # User 'yyyy' accepted at epoch 'nnnn'. <"FILE:macro", "PHID-DREV-xxxx", "PHID-MACR-yyyy", 17, ..., ...> # Object 'xxxx' uses macro 'yyyy' 17 times. Facts have no uniqueness constraints. For @vrana's reviewer responsiveness stuff, we can insert multiple rows for each reviewer, e.g. <"DREV:reviewed", "PHID-DREV-xxxx", "PHID-USER-yyyy", nnnn, ..., mmmm> # User 'yyyy' reviewed revision 'xxxx' after 'nnnn' seconds at 'mmmm'. The second value (valueY) is mostly because we need it if we sample anything (valueX = observed value, valueY = sample rate) but there might be other uses. We might need to add "objectB" at some point too -- currently we can't represent a fact like "User X used macro Y on revision Z", so it would be impossible to compute macro use rates //for a specific user// based on this schema. I think we can start here though and see how far we get. = Aggregated Facts = These aren't implemented yet, but the idea is that we can then take the "raw facts" and compute derived/aggregated/rollup facts based on the raw fact table. For example, the "count" fact can be aggregated to arrive at a count of all objects in the system. This stuff will live in a separate table which does have uniqueness constraints, and come in the next diff. We might need some kind of time series facts too, not sure about that. I think most of our use cases today are covered by raw facts + aggregated facts. Test Plan: Ran `bin/fact` commands and verified they seemed to do reasonable things. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran, majak Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3078
2012-07-27 22:34:21 +02:00
'PhabricatorFactRaw' => 'PhabricatorFactDAO',
Add FactCursors and application fact datasources Summary: - Add PhabricatorApplication. This is a general class that I have grand designs for, but used here to allow applications to provide objects for analysis by the facts appliction. - Add FactCursors, to keep track of where iterators are. - Make the daemon do something sort of useful. - Add `bin/fact cursors` for showing and managing objects and cursors. - Add some options to `bin/fact analyze`. Test Plan: - `bin/fact cursors`, `bin/fact cursors --reset DifferentialRevision`, `bin/fact cursors --reset X` - `bin/fact analyze`, `bin/fact analyze --all`, `bin/fact analyze --iterator DifferentialRevision --skip-aggregates` - `bin/phd debug fact` Reviewers: vrana, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1562 Differential Revision: https://secure.phabricator.com/D3098
2012-07-30 19:43:49 +02:00
'PhabricatorFactSimpleSpec' => 'PhabricatorFactSpec',
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',
Add a feed detail/permalink page for feed stories Summary: Ref T2852. Asana has one bug which I'm having a little trouble figuring out. I want to get more information to debug it, but I'll need them to run `bin/feed republish <story_id>` to get that data. Right now, it's incredibly hard to figure out the story ID for feed stories. So mostly this is to make that easier (click permalink; pull it out of the URL), but it also adds a little functionality and cleans the code up a bit. The page itself could be prettier and maybe some day we'll add comments or whatever, but it seems reasonably functionalish. Test Plan: {F49962} - Also loaded many pages of feed history to check that nothing broke. Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6440
2013-07-13 02:04:02 +02:00
'PhabricatorFeedDetailController' => 'PhabricatorFeedController',
Let feed panels render something meaningful-ish Summary: Ref T4986. We need to introduce alternate views to make this more pleasant, but let rendering move to engines so it can be shared between panels and controllers. I also moved some of the pagination logic in to avoid duplicating that. So far, only Feed works. I'm going to do these gradually since we have ~40-50 of them. Test Plan: - Used global search to check for collateral damage. - Used not-global search too. - Used normal feed. {F151541} Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9008
2014-05-08 17:24:47 +02:00
'PhabricatorFeedListController' => 'PhabricatorFeedController',
Push feed publishing deeper into the task queue Summary: Ref T2852. I want to model Asana integration as a response to feed events. Currently, we queue one feed event for each HTTP hook. Instead, always queue one feed event and then have it queue any necessary followup events (now, http hooks; soon, asana). Add a script to make it easy to reproducibly fire feed event publishing. Test Plan: Republished a feed event and verified it hit configured HTTP hooks correctly. $ ./bin/feed republish 5765774156541908292 --trace >>> [2] <connect> phabricator2_feed <<< [2] <connect> 1,660 us >>> [3] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [3] <query> 595 us >>> [4] <connect> phabricator2_differential <<< [4] <connect> 760 us >>> [5] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [5] <query> 478 us >>> [6] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [6] <query> 449 us >>> [7] <connect> phabricator2_user <<< [7] <connect> 1,062 us >>> [8] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [8] <query> 540 us >>> [9] <connect> phabricator2_file <<< [9] <connect> 951 us >>> [10] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [10] <query> 498 us >>> [11] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [11] <query> 507 us Republishing story... >>> [12] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [12] <query> 685 us >>> [13] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [13] <query> 489 us >>> [14] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [14] <query> 512 us >>> [15] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [15] <query> 601 us >>> [16] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [16] <query> 405 us >>> [17] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [17] <query> 551 us >>> [18] <query> SELECT story.* FROM `feed_storydata` story JOIN `feed_storyreference` ref ON ref.chronologicalKey = story.chronologicalKey WHERE (ref.chronologicalKey IN (5765774156541908292)) GROUP BY story.chronologicalKey ORDER BY story.chronologicalKey DESC <<< [18] <query> 507 us >>> [19] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [19] <query> 428 us >>> [20] <query> SELECT * FROM `differential_revision` WHERE phid IN ('PHID-DREV-ywqmrj5zgkdloqh5p3c5') <<< [20] <query> 419 us >>> [21] <query> SELECT * FROM `user` WHERE phid in ('PHID-USER-lqiz3yd7wmk64ejugvov') <<< [21] <query> 591 us >>> [22] <query> SELECT * FROM `file` WHERE phid IN ('PHID-FILE-gq6dlsysvxbn3dgwvky7') <<< [22] <query> 406 us >>> [23] <query> SELECT * FROM `user_status` WHERE userPHID IN ('PHID-USER-lqiz3yd7wmk64ejugvov') AND UNIX_TIMESTAMP() BETWEEN dateFrom AND dateTo <<< [23] <query> 593 us >>> [24] <http> http://127.0.0.1/derp/ <<< [24] <http> 746,157 us [2013-06-24 20:23:26] EXCEPTION: (HTTPFutureResponseStatusHTTP) [HTTP/500] Internal Server Error Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2852 Differential Revision: https://secure.phabricator.com/D6291
2013-06-26 01:29:47 +02:00
'PhabricatorFeedManagementRepublishWorkflow' => 'PhabricatorFeedManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFeedManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
Use ApplicationSearch in Feed Summary: Ref T2625. This doesn't do anything fancy, but gives feed a little more flexibility. Test Plan: Viewed `/feed/`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6681
2013-08-05 23:10:41 +02:00
'PhabricatorFeedSearchEngine' => 'PhabricatorApplicationSearchEngine',
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',
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',
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',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
1 => 'PhabricatorTokenReceiverInterface',
2 => 'PhabricatorSubscribableInterface',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => 'PhabricatorPolicyInterface',
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
),
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileCommentController' => 'PhabricatorFileController',
Add an icon+background selector for project images Summary: Makes it easy to choose distinctive icons for projects. Test Plan: {F71018} {F71020} {F71019} {F71021} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7333
2013-10-17 18:32:34 +02:00
'PhabricatorFileComposeController' => 'PhabricatorFileController',
Phabricator file upload application.
2011-01-23 03:33:00 +01:00
'PhabricatorFileController' => 'PhabricatorController',
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
Move ALL files to serve from the alternate file domain, not just files without "Content-Disposition: attachment" Summary: We currently serve some files off the primary domain (with "Content-Disposition: attachment" + a CSRF check) and some files off the alternate domain (without either). This is not sufficient, because some UAs (like the iPad) ignore "Content-Disposition: attachment". So there's an attack that goes like this: - Alice uploads xss.html - Alice says to Bob "hey download this file on your iPad" - Bob clicks "Download" on Phabricator on his iPad, gets XSS'd. NOTE: This removes the CSRF check for downloading files. The check is nice to have but only raises the barrier to entry slightly. Between iPad / sniffing / flash bytecode attacks, single-domain installs are simply insecure. We could restore the check at some point in conjunction with a derived authentication cookie (i.e., a mini-session-token which is only useful for downloading files), but that's a lot of complexity to drop all at once. (Because files are now authenticated only by knowing the PHID and secret key, this also fixes the "no profile pictures in public feed while logged out" issue.) Test Plan: Viewed, info'd, and downloaded files Reviewers: btrahan, arice, alok Reviewed By: arice CC: aran, epriestley Maniphest Tasks: T843 Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
'PhabricatorFileDataController' => 'PhabricatorFileController',
Allow files to be deleted Summary: A couple of people mentioned that they've had users accidentally upload sensitive files. Allow files to be deleted. (At some point it might be nice to keep the file handle around and log who deleted it, but this addresses the immediate problem without needing too much work.) Test Plan: Deleted some files. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T780 Differential Revision: https://secure.phabricator.com/D1423
2012-01-16 22:26:44 +01:00
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
Drag-and-drop upload for Maniphest Summary: This needs a bunch of UI polish (critically, it's totally undiscoverable) but it basically works correctly. I'll clean it up in some followups. Test Plan: Uploaded some files via drag-and-drop, made comments, etc. Reviewed By: aran Reviewers: tomo, aran, jungejason, tuomaspelkonen CC: anjali, aran Differential Revision: 332
2011-05-22 20:55:10 +02:00
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileEditor' => 'PhabricatorApplicationTransactionEditor',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => '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',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorFileListController' => 'PhabricatorFileController',
Use Application PHIDs in Files Summary: Ref T2715. Move files to the new stuff. Test Plan: Used `phid.query`; `phid.lookup` to find files. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6523
2013-07-22 17:02:56 +02:00
'PhabricatorFilePHIDTypeFile' => 'PhabricatorPHIDType',
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',
Complete modularization of the GC daemon Summary: This modularizes the rest of the GC submethods. Turned out there was nothing tricky. Test Plan: Ran `bin/phd debug garbage` and got reasonable looking behavior and output. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7971
2014-01-15 19:02:31 +01:00
'PhabricatorFileTemporaryGarbageCollector' => 'PhabricatorGarbageCollector',
Make file storage more testable Summary: Fixes T2474. Adds a storage dummy storage engine for unit tests, and adds a couple of simple tests for basic file storage. Test Plan: Ran `arc unit` to execute unit tests. Reviewers: kwadwon Reviewed By: kwadwon CC: aran Maniphest Tasks: T2474 Differential Revision: https://secure.phabricator.com/D4777
2013-02-06 22:37:42 +01:00
'PhabricatorFileTestCase' => 'PhabricatorTestCase',
Files Generating Summary: Ref T2903 Test Plan: Files are being generating, albeit temporary. Reviewers: epriestley, AnhNhan Reviewed By: AnhNhan CC: aran, Korvin, AnhNhan, chad Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5801
2013-05-06 19:30:24 +02:00
'PhabricatorFileTestDataGenerator' => 'PhabricatorTestDataGenerator',
File - add transactions and editor Summary: this ends up being a little weird since you can't actually edit files. Also, since we create files all sorts of ways, sometimes without even having a user, we don't bother logging transactions for those events. Fixes T3651. Turns out this work is important for T3612, which is a priority of mine to help get Pholio out the door. Test Plan: left a comment on a file. it worked! use bin/mail to verify mail content looked correct. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran, wez Maniphest Tasks: T3651, T3612 Differential Revision: https://secure.phabricator.com/D6789
2013-09-05 22:11:02 +02:00
'PhabricatorFileTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorFileTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorFileTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorFilesManagementWorkflow' => 'PhabricatorManagementWorkflow',
Make Flags policy aware Summary: Ref T1809. Ref T603. Ref T3599. Makes flags policy aware. This change reduces the utility of flag search/browse; the next change will switch it to ApplicationSearch to restore utility. Representing all that ordering in terms of cursor paging is also a giant pain. Test Plan: Viewed Differential, Flags, etc. Grepped for all PhabricatorFlagQuery callsites. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T1809, T3599 Differential Revision: https://secure.phabricator.com/D6746
2013-08-14 01:17:42 +02:00
'PhabricatorFlag' =>
array(
0 => 'PhabricatorFlagDAO',
1 => 'PhabricatorPolicyInterface',
),
Add "Flags" to allow users to collect the things they love Summary: Flags are a personal collection of things you want to take a look at later. You can use several different colors and add notes. Not really sure if this is actually a good idea or not but it was easy to build. Planned features: - Allow Herald rules to add flags. - In the "edit flag" dialog, have a "[x] Subscribe Me" checkbox that CCs you. - Support Diffusion. - Support Phriction. - Always show flags on an object if you have them (in every view)? - Edit dialog feels a little heavy? - More filtering in /flag/ tool. - Add a top-level links somewhere? Test Plan: Added, edited and removed flags from things. Viewed flags in flag view. Reviewers: aran, btrahan Reviewed By: btrahan CC: aran, epriestley, Koolvin Maniphest Tasks: T1041 Differential Revision: https://secure.phabricator.com/D2024
2012-03-28 01:22:40 +02:00
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
'PhabricatorFlagController' => 'PhabricatorController',
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
Move a bunch more rendering into SearchEngine Summary: Ref T4986. These are mostly mechanical now, I skipped a couple of slightly tricky ones. Still a bunch to go. Test Plan: For each engine: - Viewed the application; - created a panel to issue the query. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9017
2014-05-08 19:08:37 +02:00
'PhabricatorFlagListController' => 'PhabricatorFlagController',
Make Flags policy aware Summary: Ref T1809. Ref T603. Ref T3599. Makes flags policy aware. This change reduces the utility of flag search/browse; the next change will switch it to ApplicationSearch to restore utility. Representing all that ordering in terms of cursor paging is also a giant pain. Test Plan: Viewed Differential, Flags, etc. Grepped for all PhabricatorFlagQuery callsites. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T1809, T3599 Differential Revision: https://secure.phabricator.com/D6746
2013-08-14 01:17:42 +02:00
'PhabricatorFlagQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement ApplicationSearch in Flags Summary: Ref T1809. Provide ApplicationSearch to Flags and allow the user to select flags by color. @chad might have some design feedback on my control. Test Plan: {F54131} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D6747
2013-08-14 01:27:26 +02:00
'PhabricatorFlagSearchEngine' => 'PhabricatorApplicationSearchEngine',
'PhabricatorFlagSelectControl' => 'AphrontFormControl',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorFlaggableInterface' => 'PhabricatorPHIDInterface',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorFlagsUIEventListener' => 'PhabricatorEventListener',
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',
Modularize the Garbage Collector Summary: The GC is a big block of hard-coded application GCs right now. Among other things, this means third parties can't tap into the infrastructure. Modularize it into `GarbageCollector` classes. This implements only one to prove the new stuff works; I'll followup with the rest in the next diff or few depending on how much mess I run into. Test Plan: Used `bin/phd debug garbage` to run the collector in debug mode, observed reasonable output and behavior. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7970
2014-01-15 19:02:24 +01:00
'PhabricatorGarbageCollector' => 'Phobject',
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',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorGitGraphStream' => 'PhabricatorRepositoryGraphStream',
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',
Proide application-based handle loads; load Slowvote handles from the application Summary: Ref T2715. This is pretty straightforward, I think. Notes: - Long term, I want to replace `PhabricatorObjectHandleData` with `PhabricatorObjectQuery` and `PhabricatorHandleQuery`. The former's name is a relic of old Facebook stuff and unusual now that everything else uses normal queries. - I simplified the amount of work applications need to do in order to populate handles. The should just need to set names and URIs in most cases. Test Plan: Used `phid.lookup` and `phid.query` to load slowvote handles. Browsed around to load other handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6508
2013-07-21 16:03:10 +02:00
'PhabricatorHandleQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'PhabricatorHarbormasterConfigOptions' => 'PhabricatorApplicationConfigOptions',
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',
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',
Whitelist allowed editor protocols Summary: This is the other half of D8548. Specifically, the attack here was to set your own editor link to `javascript\n:...` and then you could XSS yourself. This isn't a hugely damaging attack, but we can be more certain by adding a whitelist here. We already whitelist linkable protocols in remarkup (`uri.allowed-protocols`) in general. Test Plan: Tried to set and use valid/invalid editor URIs. {F130883} {F130884} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8551
2014-03-17 21:00:37 +01:00
'PhabricatorHelpEditorProtocolController' => 'PhabricatorHelpController',
Provide basic structure for keyboard shortcuts Summary: Implements a simple infrastructure for keyboard shortcuts, see T184, and a "help" shortcut. There's a lot of room for refinement here but I think it basically works. Each shortcut can also provide a "tooltip" handler which allows it to show help when the alt/option key is held down. Test Plan: Pressed "?" and got help. Pressed "?" in various contexts where it should not activate (modifier keys, text input focused) and didn't get help. Reviewers: aran, tuomaspelkonen, jungejason CC: moskov Differential Revision: 362
2011-05-28 20:36:00 +02:00
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
Make "Home" a formal application Summary: Ref T3979. Currently, the home page lives in an old application called "directory" and is informally defined. Make it a real application called "Home", with a formal definition. It isn't launchable and can't be uninstalled. Test Plan: Loaded home, saw exact same stuff. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3979 Differential Revision: https://secure.phabricator.com/D8074
2014-01-26 21:26:13 +01:00
'PhabricatorHomeController' => 'PhabricatorController',
'PhabricatorHomeMainController' => 'PhabricatorHomeController',
Add very basic "quick create" menu Summary: Ref T3623. This is like a pre-v0, in that it doesn't have a dropdown yet. Clicking the button takes you to a page which can serve as a right click / mobile / edit target in the long run, but is obviously not great for desktop use. I'll add the dropdown in the next iteration. Test Plan: {F105631} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3623 Differential Revision: https://secure.phabricator.com/D8088
2014-01-29 05:18:01 +01:00
'PhabricatorHomeQuickCreateController' => 'PhabricatorHomeController',
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',
Add a `bin/hunks` script to manage migrations of hunk data Summary: Ref T4045. Ref T5179. While we'll eventually need to force a migration, we can let installs (particularly large installs) do an online migration for now. This moves hunks to the new storage format one at a time. (Note that nothing writes to the new store yet, so this is the only way to populate it.) WARNING: Installs, don't run this yet! It won't compress the data. Wait until it can also do compression. Test Plan: Added a `break;` after migrating one row and moved a few rows over. Spot checked them in the database and viewed the affected diffs. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4045, T5179 Differential Revision: https://secure.phabricator.com/D9291
2014-05-25 18:54:12 +02:00
'PhabricatorHunksManagementMigrateWorkflow' => 'PhabricatorHunksManagementWorkflow',
'PhabricatorHunksManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
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',
Write a very basic string extractor Summary: Ref T1139. This has some issues and glitches, but is a reasonable initial attempt that gets some of the big pieces in. We have about 5,200 strings in Phabricator. Test Plan: {F108261} Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D8138
2014-02-05 20:02:41 +01:00
'PhabricatorInternationalizationManagementExtractWorkflow' => 'PhabricatorInternationalizationManagementWorkflow',
'PhabricatorInternationalizationManagementWorkflow' => 'PhabricatorManagementWorkflow',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorIteratedMD5PasswordHasher' => 'PhabricatorPasswordHasher',
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',
Legalpad V0.2 - add mail integration Summary: Supports !unsubscribe and commenting on replies. Subscribers get mailed something reasonable. Fixes T3480. Sneaks in /LX/ support. In the near future I want to have that /LX/ be a clean "signature" page sans all the edit actions and other fluff... Will resolve this as part of T3481. Test Plan: used the metamta console to add comments and unsubscribe. added a phlog() inside mail code to verify mail bodies looked okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3480 Differential Revision: https://secure.phabricator.com/D6369
2013-07-04 01:37:05 +02:00
'PhabricatorLegalpadConfigOptions' => 'PhabricatorApplicationConfigOptions',
Move LegalpadDocument to new phid stuff Summary: ref T2715 - apologies btw as I didn't catch the "start from the bottom" ask until recently... :/ Test Plan: phid.query for some legalpad documents... booya. also loaded legalpad. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6576
2013-07-26 21:05:33 +02:00
'PhabricatorLegalpadPHIDTypeDocument' => 'PhabricatorPHIDType',
First Diff of Test Data Generator Summary: Progress to fix T2903 Test Plan: Ran './bin/lipsum help' and 'generate' workflows. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5672
2013-04-12 23:07:15 +02:00
'PhabricatorLipsumGenerateWorkflow' => 'PhabricatorLipsumManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorLipsumManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add a basic random image generator Summary: Adds an abstract base class for random image generation. Implements a concrete subclass for generating Mondrian-like images. Test Plan: {F40759} {F40760} {F40761} {F40762} {F40763} Reviewers: DeedyDas, AnhNhan Reviewed By: AnhNhan CC: chad, aran Differential Revision: https://secure.phabricator.com/D5705
2013-04-16 17:19:45 +02:00
'PhabricatorLipsumMondrianArtist' => 'PhabricatorLipsumArtist',
More phabricator organizational stuff.
2011-01-23 02:48:55 +01:00
'PhabricatorLiskDAO' => 'LiskDAO',
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',
CSRF / Logout
2011-01-31 03:52:29 +01:00
'PhabricatorLogoutController' => 'PhabricatorAuthController',
Allow macros to have associated audio and audio behaviors Summary: Ref T3887. Implements storage and editors, but not the actual audio part. Test Plan: Edited audio, audio behaviors of macros. Transactions and email looked good. Hit error cases. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3887 Differential Revision: https://secure.phabricator.com/D7159
2013-09-28 01:01:37 +02:00
'PhabricatorMacroAudioController' => 'PhabricatorMacroController',
Modernize policies in Paste and Macro Summary: Ref T603. Fixes T2823. This updates Paste and Macro. - **Paste** - Added default view policy. - I didn't add a "create" policy, since I can't come up with any realistic scenario where you'd give users access to pastes but not let them create them. - **Macro** - Added a "manage" policy, which covers creating and editing macros. This lets an install only allow "People With An Approved Sense of Humor" or whatever to create macros. - Removed the "edit" policy, since giving individual users access to specific macros doesn't make much sense to me. - Changed the view policy to the "most public" policy the install allows. - Added view policy information to the header. Also fix a couple of minor things in Maniphest. Test Plan: - Set Paste policy, created pastes via web and Conduit, saw they got the right default policies. - Set Macro policy, tried to create/edit macros with valid and unauthorized users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2823, T603 Differential Revision: https://secure.phabricator.com/D7317
2013-10-16 19:35:52 +02:00
'PhabricatorMacroCapabilityManage' => 'PhabricatorPolicyCapability',
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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorMacroListController' => 'PhabricatorMacroController',
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',
Use application PHIDs in Macro Summary: Ref T2715. Move Macro to application PHIDs. Test Plan: Used `conduit.query` to look up macros. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6556
2013-07-24 23:06:10 +02:00
'PhabricatorMacroPHIDTypeMacro' => 'PhabricatorPHIDType',
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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailImplementationMailgunAdapter' => 'PhabricatorMailImplementationAdapter',
Support SMTP as the mailer. Summary: Support SMTP as the mailer and user could turn on SMTP authentication if needed. Import PHPMailer as PHPMailerLite doesn't support SMTP. Make class PhabricatorMailImplementationPHPMailerAdapter final. Test Plan: N/A Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2139 Differential Revision: https://secure.phabricator.com/D4063
2012-12-09 11:36:40 +01:00
'PhabricatorMailImplementationPHPMailerAdapter' => 'PhabricatorMailImplementationAdapter',
PHPMailerLite
2011-01-26 18:33:31 +01:00
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
Add support for SendGrid as an outbound mail adapter Summary: SendGrid is a popular mail delivery platform, similar to Amazon SES. Provide support for delivering email via their REST API. Test Plan: Created a SendGrid account, configured my local install to use it, sent some mail, received mail. Reviewers: tuomaspelkonen, jungejason, aran CC: ccheever Differential Revision: 347
2011-05-26 19:00:26 +02:00
'PhabricatorMailImplementationSendGridAdapter' => 'PhabricatorMailImplementationAdapter',
Fix a threading issue with Amazon SES Summary: Amazon SES does not allow us to set a Message-ID header, which means that threads are incorrect in Mail.app (and presumably other applications which respect In-Reply-To and References) because the initial email does not have anything which attaches it to the rest of the thread. To fix this, never rely on Message-ID if the mailer doesn't support Message-ID. (In the Amazon SES case, Amazon generates its own Message-ID which we can't know ahead of time). I additionally used all the Lisk isolation from the other tests to make this testable and wrote tests for it. I also moved the idea of a thread ID lower in the stack and out of DifferentialMail, which should not be responsible for implementation details. NOTE: If you push this, it will cause a one-time break of threading for everyone using Outlook since I've changed the seed for generating Thread-Index. I feel like this is okay to avoid introducing more complexity here. Test Plan: Created and then updated a revision, messages delivered over Amazon SES threaded correctly in Mail.app. Verified headers. Unit tests. Reviewed By: rm Reviewers: aran, tuomaspelkonen, jungejason, rm Commenters: aran CC: aran, rm, epriestley Differential Revision: 195
2011-04-30 20:47:00 +02:00
'PhabricatorMailImplementationTestAdapter' => 'PhabricatorMailImplementationAdapter',
Make all bin/* scripts locate their workflows dynamically Summary: Ref T2015. Not directly related to Drydock, but I bumped into this. All these scripts currently enumerate their workflows explicitly. Instead, use `PhutilSymbolLoader` to automatically discover workflows. This reduces code duplication and errors (see all the bad `extends` this diff fixes) and lets third parties add new workflows (not clearly valuable?). Test Plan: Ran `bin/x help` for each modified script. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7840
2013-12-27 22:15:48 +01:00
'PhabricatorMailManagementListInboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementListOutboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementReceiveTestWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementResendWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementSendTestWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementShowInboundWorkflow' => 'PhabricatorMailManagementWorkflow',
'PhabricatorMailManagementShowOutboundWorkflow' => 'PhabricatorMailManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorMailManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add 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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMailgunConfigOptions' => 'PhabricatorApplicationConfigOptions',
Use application PHIDs for mailing lists Summary: Ref T2715. Ref T603. Ref T2625. - Implement policies. - Use policy queries. - Use ApplicationSearch. - Use application PHIDs. Test Plan: Browsed things with lists CC'd; edited lists; created a list, used `phid.query` to query handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625, T2715 Differential Revision: https://secure.phabricator.com/D6513
2013-07-21 19:42:07 +02:00
'PhabricatorMailingListPHIDTypeList' => 'PhabricatorPHIDType',
'PhabricatorMailingListQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorMailingListSearchEngine' => 'PhabricatorApplicationSearchEngine',
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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorManagementWorkflow' => 'PhutilArgumentWorkflow',
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',
Partially generalize Remarkup previews and add support to Differential Summary: Ref T3671. A lot of applications have pretty ad-hoc preview code. Clean it up a bit and add Summary preview to Differential. After ApplicationTransactions we might want to try to serialize the whole form and show a preview of all the transactions, but this seems not very useful in most cases (I'd guess that Remarkup previews are 99% of the value) and tricky to get right (e.g., adding images which don't exist yet to Pholio mocks). I think I can add this in a few other places, too. Test Plan: Edited Maniphest Tasks and Differential Revisions, mashed some buttons. Verified previews rendered correctly. Grepped for removed CSS classes (no hits). {F52907} Reviewers: btrahan, Firehed Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3671 Differential Revision: https://secure.phabricator.com/D6673
2013-08-05 19:46:39 +02:00
'PhabricatorMarkupPreviewController' => 'PhabricatorController',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorMercurialGraphStream' => 'PhabricatorRepositoryGraphStream',
Show why recipients were excluded from mail Summary: Ref T3306. This interface has a hard time balancing security/policy issues and I'm not sure what the best way forward is. Some possibilities: # We just let you see everything from the web UI. - This makes debugging easier. - Anyone who can see this stuff can trivially take over any user's account with five seconds of work and no technical expertise (reset their password from the web UI, then go read the email and click the link). # We let you see everything, but only for messages you were a recipient of or author of. - This makes it much more difficult to debug issues with mailing lists. - But maybe we could just say mailing list recipients are "public", or define some other ruleset. - Generally this gets privacy and ease of use right. # We could move the whole thing to the CLI. - Makes the UI/UX way worse. # We could strike an awkward balance between concerns, as we do now. - We expose //who// sent and received messages, but not the content of the messages. This doesn't feel great. I'm inclined to probably go with (2) and figure something out for mailing lists? Anyway, irrespective of that this should generally make things more clear, and improves the code a lot if nothing else. Test Plan: {F49546} - Looked at a bunch of mail. - Sent mail from different apps. - Checked that recipients seem correct. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3306 Differential Revision: https://secure.phabricator.com/D6413
2013-07-11 00:17:38 +02:00
'PhabricatorMetaMTAActorQuery' => 'PhabricatorQuery',
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',
When we fail to process mail, tell the user about it Summary: Ref T4371. Ref T4699. Fixes T3994. Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff. However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening. Thus: - When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address. - Rewrite most of the errors to be more detailed and informative. - Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent.."). - Remove the redundant, less sophisticated code which does something similar in Differential. Test Plan: - Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail. - Hit a bunch of different errors. - Saw reasonable error mail get sent to me. - Saw other reasonable error mail get rate limited. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3994, T4371, T4699 Differential Revision: https://secure.phabricator.com/D8692
2014-04-04 03:43:18 +02:00
'PhabricatorMetaMTAErrorMailAction' => 'PhabricatorSystemAction',
MetaMTA
2011-01-26 02:40:21 +01:00
'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',
Mailgun receive support Summary: As you've suggested, I took the SendGrid code and massaged it until it played nice with Mailgun. btw - unless I'm missing something, it appears that the SendGrid receiver lets you spoof emails (it performs no validation on the data received). Test Plan: Opened a task with Mailgun. Felt great. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4326 Differential Revision: https://secure.phabricator.com/D7989
2014-01-21 19:36:33 +01:00
'PhabricatorMetaMTAMailgunReceiveController' => 'PhabricatorMetaMTAController',
Use application PHIDs for mailing lists Summary: Ref T2715. Ref T603. Ref T2625. - Implement policies. - Use policy queries. - Use ApplicationSearch. - Use application PHIDs. Test Plan: Browsed things with lists CC'd; edited lists; created a list, used `phid.query` to query handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625, T2715 Differential Revision: https://secure.phabricator.com/D6513
2013-07-21 19:42:07 +02:00
'PhabricatorMetaMTAMailingList' =>
array(
0 => 'PhabricatorMetaMTADAO',
1 => 'PhabricatorPolicyInterface',
),
Expand aggregate email recipients prior to multiplexing Summary: Ref T4361. Before we figure out which To/CC are addressable, try to expand To/CC. Specifically, the supported expansion right now is project PHIDs expanding to all their members. Because of the way multiplexing works, we have to do this in two places: explicitly in `multiplexMail()`, and when sending mail that wasn't multiplexed. This is messy; eventually we can get rid of it (after ApplicationTransactions are everywhere). This has some rough edges, but should basically give us what we need to make stuff like projects mailable. Particularly, it deals with most issues in D7436: - I got around the resolution/multiplexing issue by resolving aggregate mailables separately from mailable actors. - We get to keep the Project PHID as a To/CC/Reviewer/Whatever until the last second. - Users won't get two emails for being a CC and also a member of a CC'd project. - We can degrade to the list stuff this way if we want, by having the project aggregate yield a single list PHID. Test Plan: Added a comment to a revision with a project reviewer, got mail to all the project's members. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4361 Differential Revision: https://secure.phabricator.com/D8117
2014-02-01 23:35:55 +01:00
'PhabricatorMetaMTAMemberQuery' => 'PhabricatorQuery',
Allow MetaMTA adapters to indicate that a mail is permanently undeliverable Summary: Currently, adapters can only fail mail temporarily. Allow them to indicate a permanent failure by throwing a special exception. Test Plan: Added and ran unit tests. Reviewers: wez, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6847
2013-08-30 17:21:50 +02:00
'PhabricatorMetaMTAPermanentFailureException' => 'Exception',
Support email replies in Phabricator Summary: Provides support for per-user x per-object unique reply-to email addresses, plus SMTP integration. This does not actually make Phabricator use these in outbound email. Test Plan: Used test console to validate in-Phabricator routing and handling. Piped emails into the "mail_handler.php" script to validate mail parsing. Configured sendmail and sent mail to Phabricator. Technically I haven't conducted all parts of this test on the same machine since I lost the will to configure more SMTP servers after configuring phabricator.com Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, epriestley, jungejason Differential Revision: 226
2011-05-05 08:09:42 +02:00
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
Begin improving the soundness of received mail Summary: We/I broke a couple of things here recently (see D5911) and are doing some work here in general (see D5912, etc.). Generally, this code is pretty oldschool and not especially well architected for modern application-oriented Phabricator. It hardcodes a lot of stuff which should be applications' responsibilites. Take the first steps toward making it more solid to reduce the risk here. In particular: - Factor out the "self mail" and "duplicate mail" checks and add unit tests. - Make Message-ID hash handling automatic. Test Plan: Ran unit tests. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D5915
2013-05-14 01:32:19 +02:00
'PhabricatorMetaMTAReceivedMailProcessingException' => 'Exception',
'PhabricatorMetaMTAReceivedMailTestCase' => 'PhabricatorTestCase',
Enable SendGrid Parse API as an inbound email handler Summary: Sendmail is seriously difficult to configure; SendGrid is extremely easy. It's also pretty expensive ($80/mo) but there are a bunch of startups that already have plans so it's effectively free for them. Test Plan: Configured SendGrid and sent reply email through it. Reviewed By: aran Reviewers: tuomaspelkonen, jungejason, aran CC: aran, epriestley Differential Revision: 376
2011-05-30 20:07:05 +02:00
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
Move functionality of PhabricatorMetaMTADaemon to a worker task Summary: This will allow sending mail to be done by task workers. See T750. Task ID: # Blame Rev: Test Plan: - started taskmaster daemon in test env - used "send new test message" feature in MetMTA (with send now unchecked) - confirmed receipt of 1 email - repeated 2 & 3 with send now checked Revert Plan: Tags: Reviewers: epriestley, jungejason Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T388, T750 Differential Revision: https://secure.phabricator.com/D1723
2012-02-28 02:11:25 +01:00
'PhabricatorMetaMTAWorker' => 'PhabricatorWorker',
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',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationAdHocFeedStory' => 'PhabricatorFeedStory',
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',
Add a "Send Test Notification" button to make testing the server easier Summary: Ref T4324. Currently, it's a bit of a pain to send yourself notifications, and often involves multiple browsers. Instead, add a button to send them. Test Plan: {F114495} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8255
2014-02-18 01:00:33 +01:00
'PhabricatorNotificationTestController' => 'PhabricatorNotificationController',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
'PhabricatorOAuthClientAuthorization' =>
array(
0 => 'PhabricatorOAuthServerDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
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
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
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',
Make OAuth client authorizations a Settings panel Summary: This modernizes and simplifies OAuth client authorizations a bit, moving them to a settings panel similar to the "Sessions" panel. Test Plan: - Viewed authorizations. - Revoked an authorization. - Created a test authorization. {F131196} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8561
2014-03-18 21:28:19 +01:00
'PhabricatorOAuthServerAuthorizationsSettingsPanel' => 'PhabricatorSettingsPanel',
Use modern UI and policies in OAuth client editing Summary: Updates this stuff a bit: - Add a global create permission for OAuth applications. The primary goal is to reduce attack surface area by making it more difficult for an adversary to do anything which requires that they create and configure an OAuth application/client. Normal users shouldn't generally need to create applications, OAuth is complex, and doing things with user accounts is inherently somewhat administrative. - Use normal policies to check create and edit permissions, now that we have infrastructure for it. - Use modern UI kit. Test Plan: - Created a client. - Edited a client. - Tried to create a client as a non-admin. - Tried to edit a client I don't own. {F131511} {F131512} {F131513} {F131514} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8562
2014-03-18 21:30:48 +01:00
'PhabricatorOAuthServerCapabilityCreateClients' => 'PhabricatorPolicyCapability',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
'PhabricatorOAuthServerClient' =>
array(
0 => 'PhabricatorOAuthServerDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorOAuthServerClientQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in OAuthServer Summary: Update the infrastructure and UI of the client list. Test Plan: {F131570} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8563
2014-03-18 21:31:04 +01:00
'PhabricatorOAuthServerClientSearchEngine' => 'PhabricatorApplicationSearchEngine',
OAuth Server -- add controllers to RUD client authorizations and CRUD clients Summary: beyond the title, this diff tweaks the test console to have a bit more functionality. also makes a small change to CSS for AphrontFormControlMarkup, which IMO fixes a display issue on https://secure.phabricator.com/settings/page/profile/ where the Profile URI is all up in the air and whatnot I think this is missing pagination. I am getting tired of the size though and will add later. See T905. Test Plan: viewed, updated and deleted client authorizations. viewed, created, updated and deleted clients Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T849, T850, T848 Differential Revision: https://secure.phabricator.com/D1683
2012-02-22 19:21:39 +01:00
'PhabricatorOAuthServerController' => 'PhabricatorController',
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',
Modernize OAuthServer PHIDs and Queries Summary: - Modernize PHID types. - Implement `PhabricatorPolicyInterface`. - Make queries policy aware. Test Plan: Browsed client and authorization lists. Reviewers: btrahan Reviewed By: btrahan Subscribers: chad, epriestley Differential Revision: https://secure.phabricator.com/D8560
2014-03-18 21:27:55 +01:00
'PhabricatorOAuthServerPHIDTypeClient' => 'PhabricatorPHIDType',
'PhabricatorOAuthServerPHIDTypeClientAuthorization' => 'PhabricatorPHIDType',
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',
Proide application-based handle loads; load Slowvote handles from the application Summary: Ref T2715. This is pretty straightforward, I think. Notes: - Long term, I want to replace `PhabricatorObjectHandleData` with `PhabricatorObjectQuery` and `PhabricatorHandleQuery`. The former's name is a relic of old Facebook stuff and unusual now that everything else uses normal queries. - I simplified the amount of work applications need to do in order to populate handles. The should just need to set names and URIs in most cases. Test Plan: Used `phid.lookup` and `phid.query` to load slowvote handles. Browsed around to load other handles. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6508
2013-07-21 16:03:10 +02:00
'PhabricatorObjectHandle' => 'PhabricatorPolicyInterface',
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',
Extract textual object list parsing from Differential Summary: Ref T2222. Currently, Differential has a fairly hairy piece of logic to parse object lists, like `Reviewers: alincoln, htaft`. Extract, generalize, and cover this. - Some of the logic can be simplified with modern ObjectQuery stuff. - Make `@username` the formal monogram for users. - Make `list@domain.com` the formal monogram for mailing lists. - Add test coverage. Test Plan: - Ran unit tests. - Called `differential.parsecommitmessage` with a bunch of real-world inputs and got sensible results. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2222 Differential Revision: https://secure.phabricator.com/D8445
2014-03-08 02:44:44 +01:00
'PhabricatorObjectListQueryTestCase' => 'PhabricatorTestCase',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PhabricatorObjectMailReceiver' => 'PhabricatorMailReceiver',
Move sender validation into MailReceiver classes Summary: Ref T1205. Finally able to delete a big chunk of this nastiness. Make MailReceivers responsible for validating senders. For object creation receivers (bugs, conpherences) this just means that users must not be disabled. For other receivers the senders must be able to see the objects, have the right hashes, etc., according to policy. Test Plan: Added a bunch of test cases (everything except policy). Verified behavior via the Receive test console. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5943
2013-05-17 12:49:29 +02:00
'PhabricatorObjectMailReceiverTestCase' => 'PhabricatorTestCase',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorObjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Move OwnersPackage to Appliation PHIDs Summary: Ref T2715. Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6572
2013-07-26 19:31:26 +02:00
'PhabricatorOwnersPHIDTypePackage' => 'PhabricatorPHIDType',
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',
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',
Make password hashing modular Summary: Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily. This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt. Test Plan: - Verified that the same stuff gets stored in the DB (i.e., no functional changes): - Logged into an old password account. - Changed password. - Registered a new account. - Changed password. - Switched back to master. - Logged in / out, changed password. - Switched back, logged in. - Ran unit tests (they aren't super extensive, but cover some of the basics). Reviewers: btrahan Reviewed By: btrahan CC: aran, kofalt Maniphest Tasks: T4443 Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 18:31:30 +01:00
'PhabricatorPasswordHasher' => 'Phobject',
'PhabricatorPasswordHasherTestCase' => 'PhabricatorTestCase',
'PhabricatorPasswordHasherUnavailableException' => 'Exception',
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',
Paste - add support for email replies and subscribers Summary: Email replies and subscribers seem to go hand in hand so deploy both at once. Test Plan: played around with bin/mail. Verified replies posted comments on the paste. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3650 Differential Revision: https://secure.phabricator.com/D6682
2013-08-06 02:11:46 +02:00
1 => 'PhabricatorSubscribableInterface',
2 => 'PhabricatorTokenReceiverInterface',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => 'PhabricatorPolicyInterface',
Implement PhabricatorProjectInterface in Paste Summary: Ref T2628. Implements PhabricatorProjectInterface (D9340) in Paste. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9341
2014-06-04 02:22:09 +02:00
5 => 'PhabricatorProjectInterface',
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
),
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteCommentController' => 'PhabricatorPasteController',
Add some create mail handlers for paste and files Summary: Fixes T1144. Though actually I think T1144 wanted some handy way to email from the command-line / arc, this is cooler. :D Test Plan: set conf properly and then ./bin/mail receive-test --as btrahan --to pasties@phabricator.dev | README --> it worked...! couldn't test files as easily but verified exception thrown when I tried to test. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1144 Differential Revision: https://secure.phabricator.com/D6622
2013-07-30 22:26:55 +02:00
'PhabricatorPasteConfigOptions' => 'PhabricatorApplicationConfigOptions',
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',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteEditor' => 'PhabricatorApplicationTransactionEditor',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPasteListController' => 'PhabricatorPasteController',
Use application PHIDs in Paste Summary: Ref T2715. Switch Paste to application PHIDs. Test Plan: Used `conduit.query`; `conduit.lookup`; grepped for constants. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6555
2013-07-24 20:32:49 +02:00
'PhabricatorPastePHIDTypePaste' => 'PhabricatorPHIDType',
Allow projects to be set as policies Summary: - Renames `PhabricatorPolicyQuery` to `PhabricatorPolicyAwareQuery` (a query which respects policy settings). - Introduces `PhabricatorPolicyQuery`, which loads available policies (e.g., "member of project X"). - Introduces `PhabricatorPolicy`, which describes a policy. - Allows projects to be set as policies. - Allows Paste policies to be edited. - Covers crazy cases where you make projects depend on themselves or each other because you are a dastardly villan. Test Plan: Set paste and project policies, including crazy policies like A -> B -> A, A -> A, etc. Reviewers: vrana, btrahan Reviewed By: vrana CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D3476
2012-09-13 19:15:08 +02:00
'PhabricatorPasteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Paste - add transactions Summary: Ref T3650. This adds a create transaction, transactions for metadata (title, langauge, view policy), and comments. Editor is used on all create /edit paths. Test Plan: made some pastes via web and email - yay. edited pastes - yay. verified txns showed up on pastes and in feed correctly. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3516, T3650 Differential Revision: https://secure.phabricator.com/D6645
2013-08-02 21:56:58 +02:00
'PhabricatorPasteTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorPasteTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorPasteTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Pastebin Summary: This is Paste. It needs some work, but epriestley recommended that I just commit something that works, and expand on that later. Specifically, it lacks the ability to view a raw paste right now, and to turn off line numbers, making it hard to copy/paste from for now. It works for showing other people code, however. Test Plan: Pasted stuff, and was able to view it, and see it in the list on /paste/. Put a file extension in the title, and saw that syntax highlighting worked as expected. Reviewers: epriestley CC: Differential Revision: 424
2011-06-10 08:53:53 +02:00
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleApproveController' => 'PhabricatorPeopleController',
Calendar upgrades Summary: Does a handful of things to make Calendar significantly more useful - Enabled overlapping events - Profile has a 'week view' of the user - Profile has a 'month view' of the users - Multiple users on a calendar are color coded - Browse view slightly more useful This stops short of implementing the new 'home' view on Calendar, mostly this is a big step though to make that happen next. Test Plan: Make lots of events on diffent users. Reviewers: epriestley, btrahan Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T2897, T4375 Differential Revision: https://secure.phabricator.com/D8317
2014-02-24 19:04:23 +01:00
'PhabricatorPeopleCalendarController' => 'PhabricatorPeopleController',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorPeopleController' => 'PhabricatorController',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleCreateController' => 'PhabricatorPeopleController',
Move "Delete User" action to user profiles Summary: Ref T4065. The existence of two separate edit workflows for users is broadly confusing to administrators. I want to unify user administration and improve administration of system agent accounts. Particularly, I plan to: - Give administrators limited access to profile editing of system agents (e.g., change profile picture). - Give administrators limited access to Settings for system agents. - Broadly, move all the weird old special editing into standard editing. Test Plan: - Hit all the errors (delete self, no username, wrong username). - Deleted a user. - Visited page as a non-admin, got 403'd. - Viewed old edit UI. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8662
2014-04-02 21:05:07 +02:00
'PhabricatorPeopleDeleteController' => 'PhabricatorPeopleController',
Implement most of the administrative UI for approval queues Summary: Nothing fancy here, just: - UI to show users needing approval. - "Approve" and "Disable" actions. - Send "Approved" email on approve. - "Approve" edit + log operations. - "Wait for Approval" state for users who need approval. There's still no natural way for users to end up not-approved -- you have to write directly to the database. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 20:24:18 +01:00
'PhabricatorPeopleDisableController' => 'PhabricatorPeopleController',
Put Disable/Admin flags on profiles Summary: Ref T4065. Moves the "disable / enable" and "make / unmake administrator" actions to profiles. Test Plan: Disabled and enabled users, and made and unmade administrators. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8666
2014-04-02 21:05:49 +02:00
'PhabricatorPeopleEmpowerController' => 'PhabricatorPeopleController',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorPeopleHovercardEventListener' => 'PhabricatorEventListener',
Added ldap import controller
2012-07-04 04:10:38 +02:00
'PhabricatorPeopleLdapController' => 'PhabricatorPeopleController',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPeopleListController' => 'PhabricatorPeopleController',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
'PhabricatorPeopleLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorPeopleLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Move Maniphest list rendering to SearchEngine Summary: Ref T4986. Moves Maniphest over. Nothing tricky here, just a complex block of rendering. Test Plan: Viewed Maniphest list. Created Maniphest panel. Used batch editor, drag-and-drop. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9139
2014-05-16 04:17:38 +02:00
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
Make user creation process simpler Summary: Fixes T4065. This divides user creation into separate "Standard User" and "Script/Bot" workflows which show only relevant fields and provide guidance. This fixes the verification mess associated with script/bot users by verifying their email addresses automatically. Test Plan: - Created a standard user. - Created a script/bot. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8674
2014-04-02 21:06:27 +02:00
'PhabricatorPeopleNewController' => 'PhabricatorPeopleController',
Use Application PHIDs for XUSR Summary: Ref T2715. XUSR -> apps Test Plan: `phid.query` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6558
2013-07-24 23:12:39 +02:00
'PhabricatorPeoplePHIDTypeExternal' => 'PhabricatorPHIDType',
Move PhabricatorUser to new phid stuff Summary: Ref T2715. Had to start loading status information in the query class. Debated trying to clean up some of the attach / load stuff but decided to just add status under the new paradigm for now. Test Plan: phid.query also made a status and checked that out. also played in conpherence. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6585
2013-07-26 23:05:19 +02:00
'PhabricatorPeoplePHIDTypeUser' => 'PhabricatorPHIDType',
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',
Improve UI for selecting profile pictures Summary: Ref T1703. Move profile pictures to a separate, dedicated interface. Instead of the 35 controls we currently provide, just show all the possible images we can find and then let the user upload an additional one if they want. Possible improvements to this interface: - Write an edge so we can show old profile pictures too. - The cropping/scaling got a bit buggy at some point, fix that. - Refresh OAuth sources which we're capable of refreshing before showing images (more work than I really want to deal with). - We could show little inset icons for the image source ("f" for Facebook, etc.) instead of just the tooltips. Test Plan: Chose images, uploaded new images, hit various error cases. {F49344} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2919, T1703 Differential Revision: https://secure.phabricator.com/D6398
2013-07-10 01:23:54 +02:00
'PhabricatorPeopleProfilePictureController' => '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',
Move "Change Username" from weird edit panel to standard object action Summary: Ref T4065. Make this work in a more standard way which administrators have a reasonable shot at finding and using. See D8662 for discussion. Test Plan: Changed a user's username. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8663
2014-04-02 21:05:19 +02:00
'PhabricatorPeopleRenameController' => 'PhabricatorPeopleController',
Implement ApplicationSearch in People Summary: Ref T2625. Fixes T2812. Implement ApplicationSearch in People. {F44788} Test Plan: Made People queries. Used Conduit. Used `@mentions`. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T2625, T2812 Differential Revision: https://secure.phabricator.com/D6092
2013-05-31 19:51:20 +02:00
'PhabricatorPeopleSearchEngine' => 'PhabricatorApplicationSearchEngine',
Successfully Generated People Summary: Ref T2903 Test Plan: Added new person whose profile was visible afterwards. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan, btrahan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5682
2013-04-15 04:09:20 +02:00
'PhabricatorPeopleTestDataGenerator' => 'PhabricatorTestDataGenerator',
Move "Send Welcome Email" to profiles and nuke old weird edit UI Summary: Ref T4065. Moves the last of the weird alternate edit UI to profiles. The old "Edit" controller is now for creation only, and the funky pencil icon is gone. Test Plan: Created accounts; sent welcome email. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4065 Differential Revision: https://secure.phabricator.com/D8670
2014-04-02 21:06:17 +02:00
'PhabricatorPeopleWelcomeController' => 'PhabricatorPeopleController',
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',
Move PhameBlog to new phid stuff Summary: Ref T2715 Test Plan: loaded phame and viewed all blogs link. did phid.query successfully Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6578
2013-07-26 21:19:12 +02:00
'PhabricatorPhamePHIDTypeBlog' => 'PhabricatorPHIDType',
Move PhamePost to new phid stuff Summary: Ref T2715 Test Plan: phid.query and a brief phame post read Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6579
2013-07-26 22:15:08 +02:00
'PhabricatorPhamePHIDTypePost' => 'PhabricatorPHIDType',
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',
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',
Prepare the policy rule edit endpoint for integration Summary: Ref T603. Allow the endpoint to take an existing policy PHID to populate the editor and return a useful datastructure. Test Plan: In the next revision, actually hooked this up. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7299
2013-10-14 21:07:31 +02:00
'PhabricatorPolicy' =>
array(
0 => 'PhabricatorPolicyDAO',
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
'PhabricatorPolicyAwareQuery' => 'PhabricatorOffsetPagedQuery',
'PhabricatorPolicyAwareTestQuery' => 'PhabricatorPolicyAwareQuery',
Allow applications to define new policy capabilities Summary: Ref T603. I want to let applications define new capabilities (like "can manage global rules" in Herald) and get full support for them, including reasonable error strings in the UI. Currently, this is difficult for a couple of reasons. Partly this is just a code organization issue, which is easy to fix. The bigger thing is that we have a bunch of strings which depend on both the policy and capability, like: "You must be an administrator to view this object." "Administrator" is the policy, and "view" is the capability. That means every new capability has to add a string for each policy, and every new policy (should we introduce any) needs to add a string for each capability. And we can't do any piecemeal "You must be a {$role} to {$action} this object" becuase it's impossible to translate. Instead, make all the strings depend on //only// the policy, //only// the capability, or //only// the object type. This makes the dialogs read a little more strangely, but I think it's still pretty easy to understand, and it makes adding new stuff way way easier. Also provide more context, and more useful exception messages. Test Plan: - See screenshots. - Also triggered a policy exception and verified it was dramatically more useful than it used to be. Reviewers: btrahan, chad Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7260
2013-10-07 22:28:58 +02:00
'PhabricatorPolicyCapability' => 'Phobject',
'PhabricatorPolicyCapabilityCanEdit' => 'PhabricatorPolicyCapability',
'PhabricatorPolicyCapabilityCanJoin' => 'PhabricatorPolicyCapability',
'PhabricatorPolicyCapabilityCanView' => 'PhabricatorPolicyCapability',
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',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyController' => 'PhabricatorController',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyDAO' => 'PhabricatorLiskDAO',
Make Maniphest list page react to viewer capabilities Summary: Ref T603. Basically: - Hide "Reports". - Hide "batch edit" and "export to excel". - Hide reprioritization controls. - I left the edit controls, they show a "login to continue" dialog when hit. - Allow tokenizer results to fill for public users. - Fix a bug where membership in projects was computed incorrectly in certain cases. - Add a unit test covering the project membership bug. Test Plan: Viewed /maniphest/ when logged out, and while logged in. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7126
2013-09-25 22:45:04 +02:00
'PhabricatorPolicyDataTestCase' => 'PhabricatorTestCase',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyEditController' => 'PhabricatorPolicyController',
Upgrade phabricator to libphutil v2 Summary: Mechanical changes from D2588. No "Class.php" moves yet. Test Plan: See D2588. Reviewers: vrana, btrahan, jungejason Reviewed By: vrana CC: aran Maniphest Tasks: T1103 Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 23:26:29 +02:00
'PhabricatorPolicyException' => 'Exception',
Explain policy exception rules to users Summary: Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task". This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road. Test Plan: See screenshot. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 17:43:41 +02:00
'PhabricatorPolicyExplainController' => 'PhabricatorPolicyController',
Work around a bug in PHP 5.3-ish with abstract methods in interfaces Summary: @chad is hitting an issue described in P961, which I think is this bug in PHP: https://bugs.php.net/bug.php?id=43200 Work around it by defining a "PHIDInterface" and having both "Flaggable" and "Policy" extend it, so that there is only one `getPHID()` declaration. Test Plan: shrug~ Reviewers: chad, btrahan Reviewed By: chad CC: chad, aran Differential Revision: https://secure.phabricator.com/D7408
2013-10-26 00:58:17 +02:00
'PhabricatorPolicyInterface' => 'PhabricatorPHIDInterface',
Add a very simple `bin/policy` script for CLI policy administration Summary: Ref T603. I want to provide at least a basic CLI tool for fixing policy problems, since there are various ways users can lock themselves out of objects right now. Although I imagine we'll solve most of them in the application eventually, having a workaround in the meantime will probably make support a lot easier. This implements `bin/policy show <object>`, which shows an object's policy settings. In a future diff, I'll implement something like `bin/policy set --capability view --policy users <object>`, although maybe just `bin/policy unlock <object>` (which sets view and edit to "all users") would be better for now. Whichever way we go, it will be some blanket answer to people showing up in IRC having locked themselves out of objects which unblocks them while we work on preventing the issue in the first place. Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7171
2013-09-29 18:06:41 +02:00
'PhabricatorPolicyManagementShowWorkflow' => 'PhabricatorPolicyManagementWorkflow',
Add `bin/policy unlock` Summary: Ref T603. We might need a fine-grained CLI tool later on, but here's a bat we can bludgeon things with. Test Plan: - Ran `bin/policy unlock D12` (adjusted policies). - Ran `bin/policy unlock rPca85c457ebcb` (got "not mutable" stuff). Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7189
2013-10-02 01:01:15 +02:00
'PhabricatorPolicyManagementUnlockWorkflow' => 'PhabricatorPolicyManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorPolicyManagementWorkflow' => 'PhabricatorManagementWorkflow',
Add storage for custom policies Summary: Ref T603. Allows custom policies to be saved. No integration with policy controls yet. Test Plan: mysql> select * from policy where id = 3\G *************************** 1. row *************************** id: 3 phid: PHID-PLCY-e4v2fnbyuibi4supl5tn rules: [{"action":"allow","rule":"PhabricatorPolicyRuleAdministrators","value":null},{"action":"allow","rule":"PhabricatorPolicyRuleProjects","value":["PHID-PROJ-cwovm5gn2ilubjehcdgd"]},{"action":"allow","rule":"PhabricatorPolicyRuleLunarPhase","value":"new"}] defaultAction: deny dateCreated: 1381437466 dateModified: 1381437466 1 row in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7282
2013-10-11 01:09:51 +02:00
'PhabricatorPolicyPHIDTypePolicy' => 'PhabricatorPHIDType',
Prepare the policy rule edit endpoint for integration Summary: Ref T603. Allow the endpoint to take an existing policy PHID to populate the editor and return a useful datastructure. Test Plan: In the next revision, actually hooked this up. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7299
2013-10-14 21:07:31 +02:00
'PhabricatorPolicyQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyRuleAdministrators' => 'PhabricatorPolicyRule',
Legalpad - add policy rule for legalpad document signatures Summary: Ref T3116. This creates a policy rule where you can require a signature on a given legalpad document. NOTE: signatures must be for the *latest* document version. Test Plan: made a task have a custom policy requiring a legalpad signature. verified non-signers were locked out. Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T3116 Differential Revision: https://secure.phabricator.com/D7977
2014-01-16 01:48:44 +01:00
'PhabricatorPolicyRuleLegalpadSignature' => 'PhabricatorPolicyRule',
Custom Policy Editor Summary: Ref T603. This isn't remotely usable yet, but I wanted to get any feedback before I build it out anymore. I think this is a reasonable interface for defining custom policies? It's basically similar to Herald, although it's a bit simpler. I imagine users will rarely interact with this, but this will service the high end of policy complexity (and allow the definition of things like "is member of LDAP group" or whatever). Test Plan: See screenshots. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, asherkin Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7217
2013-10-09 23:05:10 +02:00
'PhabricatorPolicyRuleLunarPhase' => 'PhabricatorPolicyRule',
'PhabricatorPolicyRuleProjects' => 'PhabricatorPolicyRule',
'PhabricatorPolicyRuleUsers' => 'PhabricatorPolicyRule',
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',
update library map (from D3200)
2012-08-10 00:42:44 +02:00
'PhabricatorProject' =>
array(
0 => 'PhabricatorProjectDAO',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
1 => 'PhabricatorFlaggableInterface',
2 => 'PhabricatorPolicyInterface',
Make Projects a PhabricatorSubscribableInterface, but with restricted defaults Summary: Ref T4379. I want project subscriptions to work like this (yell if this seems whacky, since it makes subscriptions mean somethign a little different for projects than they do for other objects): - You can only subscribe to a project if you're a project member. - When you're added as a member, you're added as a subscriber. - When you're removed as a member, you're removed as a subscriber. - While you're a member, you can optionally unsubscribe. From a UI perspective: - We don't show the subscriber list, since it's going to be some uninteresting subset of the member list. - We don't show CC transactions in history, since they're an uninteresting near-approximation of the membership transactions. - You only see the subscription controls if you're a member. To do this, I've augmented `PhabricatorSubscribableInterface` with two new methods. It would be nice if we were on PHP 5.4+ and could just use traits for this, but we should get data about version usage before we think about this. For now, copy/paste the default implementations into every implementing class. Then, I implemented the interface in `PhabricatorProject` but with alternate defaults. Test Plan: - Used the normal interaction on existing objects. - This has no actual effect on projects, verified no subscription stuff mysteriously appeared. - Hit the new error case by fiddling with the UI. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8165
2014-02-10 23:29:17 +01:00
3 => 'PhabricatorSubscribableInterface',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
4 => 'PhabricatorCustomFieldInterface',
Merge the new navigation design For discussion, see T5241.
2014-06-04 00:47:47 +02:00
5 => 'PhabricatorDestructableInterface',
update library map (from D3200)
2012-08-10 00:42:44 +02:00
),
Move "Archive Project" to a standard, separate action Summary: Ref T4379. Projects currently include their "delete/disable" function as part of edit, which is atypical. Instead, provide it as a first-class action. This is primarily for consistency between applications. (The action list on projects is getting pretty huge, but we can deal with that separately; I have some ideas.) Test Plan: Archived/unarchived a project. Edited a project. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8177
2014-02-10 23:30:47 +01:00
'PhabricatorProjectArchiveController' => 'PhabricatorProjectController',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectBoardController' => 'PhabricatorProjectController',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectBoardDeleteController' => 'PhabricatorProjectBoardController',
'PhabricatorProjectBoardEditController' => 'PhabricatorProjectBoardController',
'PhabricatorProjectBoardViewController' => 'PhabricatorProjectBoardController',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumn' =>
array(
0 => 'PhabricatorProjectDAO',
1 => 'PhabricatorPolicyInterface',
Merge the new navigation design For discussion, see T5241.
2014-06-04 00:47:47 +02:00
2 => 'PhabricatorDestructableInterface',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
),
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnDetailController' => 'PhabricatorProjectBoardController',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectColumnQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Workboards - add column detail page Summary: followup to D8544. This ends up creating an editor + transactions to get the job done. Test Plan: made a column - saw a nice created transaction. edited the name - saw a nice name edit. deleted the column - saw a deleted transaction, updated "deleted" ui, and hte action change to activate. "Activated" the column and saw a transaction and updated UI. Tried to delete a column with tasks in it and got an error. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D8620
2014-03-26 22:40:47 +01:00
'PhabricatorProjectColumnTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorProjectColumnTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorProjectColumnTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectConfigOptions' => 'PhabricatorApplicationConfigOptions',
'PhabricatorProjectConfiguredCustomField' =>
array(
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
0 => 'PhabricatorProjectStandardCustomField',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
1 => 'PhabricatorStandardCustomFieldInterface',
),
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',
Implement custom fields in Projects Summary: Ref T4379. Ref T3794. Fixes T4010. This brings CustomFields to projects. My primary goal is to get rid of the special casing around project profiles and profile editing, so all edits are ApplicationTransactions. Particularly, I want to make the "blurb/description" field a custom field which goes through builtin infrastructure. A distant secondary goal is that this is a feature which users like/want because users like/want features. Test Plan: Added a custom field and examined it in the edit, view, and search interfaces. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3794, T4010, T4379 Differential Revision: https://secure.phabricator.com/D8180
2014-02-10 23:31:34 +01:00
'PhabricatorProjectCustomField' => 'PhabricatorCustomField',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
'PhabricatorProjectCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'PhabricatorProjectCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectDescriptionField' => 'PhabricatorProjectStandardCustomField',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditDetailsController' => 'PhabricatorProjectController',
Project - add ability to select an icon for typeaheads and such Summary: Fixes T5090. Introduced getIcon into Handle stack which allows you to specify a per handle icon. getIcon falls back ot getTypeIcon. Test Plan: changed the icon on a project a bunch. verified transactions showed up. verified icon showed up in typeahead. verified icon showed up in tokens that were pre-generated (not typed in). units test passed. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5090 Differential Revision: https://secure.phabricator.com/D9264
2014-05-23 19:41:24 +02:00
'PhabricatorProjectEditIconController' => 'PhabricatorProjectController',
Merge some of the project editing options into an edit UI Summary: Ref T4426. This moves "Edit Details", "Edit Picture", and "Archive" to a separate "Edit" interface. "History" becomes part of this UI. Test Plan: {F114417} {F114418} Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T4426 Differential Revision: https://secure.phabricator.com/D8248
2014-02-17 05:17:52 +01:00
'PhabricatorProjectEditMainController' => 'PhabricatorProjectController',
'PhabricatorProjectEditPictureController' => 'PhabricatorProjectController',
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',
Project - add ability to select an icon for typeaheads and such Summary: Fixes T5090. Introduced getIcon into Handle stack which allows you to specify a per handle icon. getIcon falls back ot getTypeIcon. Test Plan: changed the icon on a project a bunch. verified transactions showed up. verified icon showed up in typeahead. verified icon showed up in tokens that were pre-generated (not typed in). units test passed. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T5090 Differential Revision: https://secure.phabricator.com/D9264
2014-05-23 19:41:24 +02:00
'PhabricatorProjectIcon' => 'Phobject',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhabricatorProjectListController' => 'PhabricatorProjectController',
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',
Use standard UI kit on project member page Summary: Fixes T4400. Removes very, very old "PhabricatorObjectListView", which was only used here. Test Plan: {F132249} Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley, chad Maniphest Tasks: T4400 Differential Revision: https://secure.phabricator.com/D8574
2014-03-20 03:30:27 +01:00
'PhabricatorProjectMembersRemoveController' => 'PhabricatorProjectController',
Send appropriate requests to the server when dragging cards on project boards Summary: Ref T1344. Makes requests to the server, which are received and ignored. Performs appropriate locking/unlocking/enabling/disabling on the client. Test Plan: Dragged stuff around, saw it enable/disable/send correctly. Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7943
2014-01-13 21:24:36 +01:00
'PhabricatorProjectMoveController' => 'PhabricatorProjectController',
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',
Add a secret board view to Projects Summary: Ref T1344. This is //very// rough. Some UI issues: - Empty states for the board and columns are junky. - Column widths are crazy. I think we need to set them to fixed-width, since we may have an arbitrarily large number of columns? - I don't think we have the header UI elements in M10 yet and that mock is pretty old, so I sort of very roughly approximated it. - What should we do when you click a task title? Popping the whole task in a dialog is possible but needs a bunch of work to actually work. Might need to build "sheets" or something. - Icons are slightly clipped for some reason. - All the backend stuff is totally faked. Generally, my plan is just to use these to implement all of T390. Specifically: - "Kanban" projects will have "Backlog" on the left. You'll drag them toward the right as you make progress. - "Milestone" projects will have "No Milestone" on the left, then "Milestone 9", "Milestone 8", etc. - "Sprint" projects will have "Backlog" on the left, then "Sprint 31", "Sprint 30", etc. So all of these things end up being pretty much exactly the same, with some minor text changes and new columns showing up on the left vs the right or whatever. Test Plan: See screenshot. Reviewers: chad, btrahan Reviewed By: btrahan CC: chad, aran, sascha-egerer Maniphest Tasks: T1344 Differential Revision: https://secure.phabricator.com/D7374
2013-10-22 06:11:36 +02:00
'PhabricatorProjectPHIDTypeColumn' => 'PhabricatorPHIDType',
Use Application PHIDs in Projects Summary: Ref T2715. Move Projects to the new stuff. Test Plan: Used `phid.query` to load projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6526
2013-07-22 18:26:26 +02:00
'PhabricatorProjectPHIDTypeProject' => 'PhabricatorPHIDType',
Rough cut of projects. Summary: Test Plan: Reviewers: CC:
2011-02-21 03:41:23 +01:00
'PhabricatorProjectProfileController' => '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',
Use ApplicationSearch in projects Summary: Ref T2715. I stripped a bunch of stuff from the list since it was buggy, slow, or both. Some day, we'll rebuild it. Test Plan: {F51128} Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6525
2013-07-22 17:34:35 +02:00
'PhabricatorProjectSearchEngine' => 'PhabricatorApplicationSearchEngine',
Index projects in the main search index Summary: Part one of a large and complicated plot: - The last filter for Maniphest "pro" queries is "Group By". - This is currently executed in a convoluted and ridiculous way, loading massive amounts of data. - The primary reason it works like it does is that we don't have a project name index available in Maniphest, so we can't sort in the DB. - So, I want to provide a name index to Maniphest and push this work to the DB. To do that, my plan is: - Index projects in Search. - Add a "did update index" event. - Have Maniphest listen for it. - When projects are updated, update their indexes in Maniphest. - Rewrite the giant mess of "group by: project" to be somewhat reasonable. - This may also extend to some future "group by: assignee". This is the first small step down this path, which just indexes projects in search. Test Plan: Ran `bin/search index --type project`, then searched for projects. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6955
2013-09-12 22:05:19 +02:00
'PhabricatorProjectSearchIndexer' => 'PhabricatorSearchDocumentIndexer',
Projects - add "Additional Hashtags" to projects Summary: Fixes T4021. Chooses to keep a "primary" slug based off the name - including all that lovely logic - and allow the user to specify "additional" slugs. Expose these as "hashtags" to the user. Sets us up for a fun diff where we can delete all the Project => Phriction automagicalness. In terms of this diff, see the TODOs i added. Test Plan: added a primary slug as an additional slug - got an error. added a slug in use on another project - got an error. added multiple good slugs and they worked. removed slugs and it worked. made some remark using multiple new slugs and they all linked to the correct project ran epriestley's case - Create project "A". - Give it additional slug "B". - Try to create project "B". and i got a nice error about hashtag collision Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, Korvin Maniphest Tasks: T4021 Differential Revision: https://secure.phabricator.com/D9250
2014-05-22 20:19:03 +02:00
'PhabricatorProjectSlug' => 'PhabricatorProjectDAO',
Migrate project blurb/description to standard custom field storage Summary: Ref T4379. Major goal here is to remove `ProjectProfile` so all edits use ApplicationTransactions. This also makes things more flexible, allowing users to disable this field if they don't like it. Test Plan: Ran migration, verified data survived, edited/created projects, reordered fields. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8182
2014-02-10 23:31:57 +01:00
'PhabricatorProjectStandardCustomField' =>
array(
0 => 'PhabricatorProjectCustomField',
1 => 'PhabricatorStandardCustomFieldInterface',
),
Finished Project Generation Summary: Progress on T2903 Test Plan: Projects are generating. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2903 Differential Revision: https://secure.phabricator.com/D5794
2013-04-29 21:17:55 +02:00
'PhabricatorProjectTestDataGenerator' => 'PhabricatorTestDataGenerator',
Move Project transaction storage to modern tables Summary: Ref T4010. Projects have a weird proto-version of ApplicationTransactions which is very similar but not quite the same. Move the storage to a modern format, but keep all the other code for now. Test Plan: Migrated project transactions; edited projects. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7370
2013-10-22 22:49:28 +02:00
'PhabricatorProjectTransaction' => 'PhabricatorApplicationTransaction',
Implement "Edit Members" and "Join/Leave" with real ApplicationTransactions Summary: Ref T4379. Projects has been partially converted to ApplicationTransactions, but the rough state of the world is that all the //storage// is modern, but most of the stuff on top isn't yet. Particularly, there's a `PhabricatorProjectEditor` which is //not// a subclass of `PhabricatorApplicationTransactionEditor`, but which fakes its way through writing reasonable data into modern storage. This introduces a real transaction editor, `PhabricatorProjectTransactionEditor`, with the eventual goal of moving all of the old functionality into it and deleting the old class. This diff only moves the membership transaction into new code (it doesn't even move all of it -- when we create a project, we add the author as a member, and that can't move quite yet since there are other transactions at the same time). Test Plan: - Created a new project. - Edited members. - Joined / left project. - This already has a pile of unit test coverage. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4379 Differential Revision: https://secure.phabricator.com/D8167
2014-02-10 23:30:00 +01:00
'PhabricatorProjectTransactionEditor' => 'PhabricatorApplicationTransactionEditor',
Add project history and title strings Summary: Ref T4010. Adds a history page and restores the transaction title strings, which previously sort-of existed in the defunct feed story class. Test Plan: See screenshots. Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T4010 Differential Revision: https://secure.phabricator.com/D7371
2013-10-22 22:49:37 +02:00
'PhabricatorProjectTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Implement PhabricatorProjectInterface for marking that objects can be tagged with projects Summary: Ref T2628. This makes Transactions understand objects that can have project relationships, extract project mentions, and handle watching. Test Plan: See next diff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T2628 Differential Revision: https://secure.phabricator.com/D9340
2014-06-04 02:19:40 +02:00
'PhabricatorProjectUIEventListener' => 'PhabricatorEventListener',
Add a Join / Leave button to Projects Summary: Make it easy to join or leave (well, slightly less easy) a project. Publish join/leave to feed. Fix a couple of membership editor bugs. Test Plan: Joined, left a project. Reviewers: btrahan, jungejason Reviewed By: btrahan CC: aran, epriestley Maniphest Tasks: T681 Differential Revision: https://secure.phabricator.com/D1485
2012-01-25 20:51:20 +01:00
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
Allow projects to be "watched", sort of a super-subscribe Summary: Ref T4967. Adds a "Watch" relationship to projects, which is stronger than member/subscribed. Specifically, when a task is tagged with a project, we'll include all project watchers in the email/notifications. Normally we don't include projects unless they're explicitly CC'd, or have some other active role in the object (like being a reviewer or auditor). This allows you to closely follow a project without needing to write a Herald rule for every project you care about. Test Plan: - Watched/unwatched a project. - Tested the watch/subscribe/member relationships: - Watching implies subscribe. - Joining implies subscribe. - Leaving implies unsubscribe + unwatch. - You can't unsubscribe until you unwatch (slightly better would be unsubscribe implies unwatch, but this is a bit tricky). - Watched a project, then recevied email about a tagged task without otherwise being involved. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4967 Differential Revision: https://secure.phabricator.com/D9185
2014-05-19 21:40:57 +02:00
'PhabricatorProjectWatchController' => 'PhabricatorProjectController',
Move 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',
Implement Graphviz, Figlet and Cowsay as Remarkup interpreter blocks Summary: Fixes T3274. Fixes T3964. Ref T3591. Test Plan: {F70928} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3274, T3964, T3591 Differential Revision: https://secure.phabricator.com/D7332
2013-10-17 04:12:14 +02:00
'PhabricatorRemarkupBlockInterpreterCowsay' => 'PhutilRemarkupBlockInterpreter',
'PhabricatorRemarkupBlockInterpreterFiglet' => 'PhutilRemarkupBlockInterpreter',
'PhabricatorRemarkupBlockInterpreterGraphviz' => 'PhutilRemarkupBlockInterpreter',
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',
Make remarkup rules runtime-pluggable in a reasonable way Summary: Gets rid of some old Differential-specific nonsense and replaces it with general runtime-pluggable Remarkup rules. Facebook: This removes two options which may be in use. Have any classes being added via config here just subclass the new abstract bases instead. This should take 5 seconds to fix. You can adjust order by overriding `getPriority()` on the rules, if necessary. Test Plan: See comments. Reviewers: btrahan Reviewed By: btrahan CC: FacebookPOC, andrewjcg, aran Differential Revision: https://secure.phabricator.com/D7393
2013-10-25 02:26:07 +02:00
'PhabricatorRemarkupCustomBlockRule' => 'PhutilRemarkupEngineBlockRule',
'PhabricatorRemarkupCustomInlineRule' => 'PhutilRemarkupRule',
Make the "NOTE:" text bold and slightly darker Summary: See screenshot. This does look like an improvement to me. Test Plan: {F133255} Reviewers: btrahan, chad Reviewed By: chad Subscribers: epriestley, chad Differential Revision: https://secure.phabricator.com/D8597
2014-03-23 02:06:46 +01:00
'PhabricatorRemarkupExample' => 'PhabricatorUIExample',
Use ApplicationSearch in Applications application Summary: Ref T603. OMG SO META Test Plan: See screenshot. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7197
2013-10-02 22:13:07 +02:00
'PhabricatorRemarkupRuleEmbedFile' => 'PhabricatorRemarkupRuleObject',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
2 => 'PhabricatorFlaggableInterface',
3 => 'PhabricatorMarkupInterface',
Allow repositories to be deleted using `./bin/remove`. Summary: Currently, repositories can be deleted using `./bin/repository delete`. It makes sense to expose this operate to the `./bin/remove` script as well, for consistency. Test Plan: Deleted a repository with `./bin/remove rTEST`. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9350
2014-06-03 02:11:58 +02:00
4 => 'PhabricatorDestructableInterface',
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
),
move repository arcanist projects over to new phid stuff Summary: also submit casual entry for longest class name award with new query class. Ref T2715 Test Plan: phid.query and saw the right arcanist project Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6586
2013-07-26 23:33:31 +02:00
'PhabricatorRepositoryArcanistProject' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
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',
move repository arcanist projects over to new phid stuff Summary: also submit casual entry for longest class name award with new query class. Ref T2715 Test Plan: phid.query and saw the right arcanist project Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6586
2013-07-26 23:33:31 +02:00
'PhabricatorRepositoryArcanistProjectQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Audit - move over to application search Summary: ...also kills off "PhabricatorAuditCommitQuery" and "PhabricatorAuditQuery", by moving the work to "DiffusionCommitQuery". Generally cleans up some code around the joint on this too. Also provides policies for audit requests, which is basically the policy for the underlying commit. Fixes T4715. (For the TODO I added about files, I just grabbed T4713.) Test Plan: Audit: verified the three default views all showed the correct things, including highligthing. did some custom queries and got the correct results. Diffusion: verified "blame view" still worked. verified paths were highlighted for packages i owned. Home: verified audit boxes showed up with proper commits w/ audits bin/audit: played around with it via --dry-run and got the right audits back Reviewers: epriestley Reviewed By: epriestley Subscribers: chad, epriestley, Korvin Maniphest Tasks: T4715 Differential Revision: https://secure.phabricator.com/D8805
2014-04-27 18:43:05 +02:00
'PhabricatorRepositoryAuditRequest' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
2 => 'PhabricatorFlaggableInterface',
3 => 'PhabricatorTokenReceiverInterface',
Add `bin/harbormaster` to make builds easier to debug Summary: Ref T1049. Adds `bin/harbormaster` and `bin/harbormaster build` for applying plans from the console. Since this gets `--trace`, it's much easier to debug what's going on. This doesn't work properly with some of the Drydock steps yet, I need to look at those. I think `setRunAllTasksInProcess` probably obsoletes some of the mechanisms. It might also not work with "Wait for Builds" but I didn't check. Test Plan: Used `bin/harbormaster` to run a bunch of builds. Ran builds from web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7825
2013-12-26 19:40:52 +01:00
4 => 'HarbormasterBuildableInterface',
Add CustomField to Diffusion and add a "branches" field Summary: Ref T4588. Request from @zeeg. Adds a "BRANCHES" field to commit emails, so the branches the commit appears on are shown. I've implemented this with CustomField, but in a very light way. Test Plan: Used `scripts/repository/reparse.php --herald` to generate mail, got a BRANCHES section where applicable. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley, zeeg Maniphest Tasks: T4588 Differential Revision: https://secure.phabricator.com/D8501
2014-03-12 19:30:33 +01:00
5 => 'PhabricatorCustomFieldInterface',
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',
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryDiscoveryEngine' => 'PhabricatorRepositoryEngine',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryEditor' => 'PhabricatorApplicationTransactionEditor',
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',
Move Git discovery into DiscoveryEngine Summary: Ref T4327. Consolidates and simplifies infrastructure: - Moves Git discovery into DiscoveryEngine. - Collapses a bunch of the Git and Mercurial code related to stream discovery. - Removes all cach code from PullLocal daemon (it's no longer called). - Adds basic unit tests for Git and Mercurial discovery. Various cleanup: - Makes GitStream and MercurialStream extend a common base. - Improves performance of MercurialStream in some cases, by requiring fewer commits be output and parsed. - Makes mirroring exceptions easier to debug. - Fixes discovery of Mercurial repositories with multiple branch heads. - Adds some missing `pht()`. Test Plan: I tested this fairly throughly because I think this phase is complete: - Made new repositories in multiple VCSes and did full imports. - Particularly, I reimported Arcanist to make sure that TODO was resolved. I think it was related to the toposort stuff. - Pushed commits to multiple VCSes. - Pushed commits to a non-close branch, then pushed a merge commit. Observed commits import initially as non-close, then get flagged for close. - Started full daemons and resolved various minor issues that showed up in the daemon log until everything ran cleanly. - Basically spent about 30 minutes banging on this in every way I could think of to try to break it. I found and fixed some minor stuff, but it seems solid. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7987
2014-01-17 00:31:52 +01:00
'PhabricatorRepositoryGraphStream' => 'Phobject',
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',
Implement a chunked, APC-backed graph cache Summary: Ref T2683. This is a refinement and simplification of D5257. In particular: - D5257 only cached the commit chain, not path changes. This meant that we had to go issue an awkward query (which was slow on Facebook's install) periodically while reading the cache. This was reasonable locally but killed performance at FB scale. Instead, we can include path information in the cache. It is very rare that this is large except in Subversion, and we do not need to use this cache in Subversion. In other VCSes, the scale of this data is quite small (a handful of bytes per commit on average). - D5257 required a large, slow offline computation step. This relies on D9044 to populate parent data so we can build the cache online at will, and let it expire with normal LRU/LFU/whatever semantics. We need this parent data for other reasons anyway. - D5257 separated graph chunks per-repository. This change assumes we'll be able to pull stuff from APC most of the time and that the cost of switching chunks is not very large, so we can just build one chunk cache across all repositories. This allows the cache to be simpler. - D5257 needed an offline cache, and used a unique cache structure. Since this one can be built online it can mostly use normal cache code. - This also supports online appends to the cache. - Finally, this has a timeout to guarantee a ceiling on the worst case: the worst case is something like a query for a file that has never existed, in a repository which receives exactly 1 commit every time other repositories receive 4095 commits, on a cold cache. If we hit cases like this we can bail after warming the cache up a bit and fall back to asking the VCS for an answer. This cache isn't perfect, but I believe it will give us substantial gains in the average case. It can often satisfy "average-looking" queries in 4-8ms, and pathological-ish queries in 20ms on my machine; `hg` usually can't even start up in less than 100ms. The major thing that's attractive about this approach is that it does not require anything external or complicated, and will "just work", even producing reasonble improvements for users without APC. In followups, I'll modify queries to use this cache and see if it holds up in more realistic workloads. Test Plan: - Used `bin/repository cache` to examine the behavior of this cache. - Did some profiling/testing from the web UI using `debug.php`. - This //appears// to provide a reasonable fast way to issue this query very quickly in the average case, without the various issues that plagued D5257. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley, jhurwitz Maniphest Tasks: T2683 Differential Revision: https://secure.phabricator.com/D9045
2014-05-10 19:10:13 +02:00
'PhabricatorRepositoryManagementCacheWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementDiscoverWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add `bin/repository edit` for CLI repository editing Summary: Ref T4039. This is mostly to deal with that, to prevent the security issues associated with mutable local paths. The next diff will lock them in the web UI. I also added a confirmation prompt to `bin/repository delete`, which was a little scary without one. See one comment inline about the `--as` flag. I don't love this, but when I started adding all the stuff we'd need to let this transaction show up as "Administrator" it quickly got pretty big. Test Plan: Ran `bin/repository edit ...`, saw an edit with a transaction show up on the web UI. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4039 Differential Revision: https://secure.phabricator.com/D7579
2013-11-13 20:26:05 +01:00
'PhabricatorRepositoryManagementEditWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add an administrative `bin/repository importing` command to list importing commits Summary: Ref T4068. Adds a command to list all commits in an "importing" status. This will allow users to use `reparse.php` to diagnose and repair issues. Test Plan: - Ran `bin/repository importing P`, etc. - Used `reparse.php` to reparse some commit stages and saw status update correctly. - Ran on a repo with no importing commits. - Ran with `... --simple | xargs`, which saves us having to put an `awk` or something in there for users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7515
2013-11-06 20:26:41 +01:00
'PhabricatorRepositoryManagementImportingWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementListWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Provide a standalone query for resolution of commit author/committer into Phabricator users Summary: Ref T4195. To implement the "Author" and "Committer" rules, I need to resolve author/committer strings into Phabricator users. The code to do this is currently buried in the daemons. Extract it into a standalone query. I also added `bin/repository lookup-users <commit>` to test this query, both to improve confidence I'm getting this right and to provide a diagnostic command for users, since there's occasionally some confusion over how author/committer strings resolve into valid users. Test Plan: I tested this using `bin/repository lookup-users` and `reparse.php --message` on Git, Mercurial and SVN commits. Here's the `lookup-users` output: >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIS3 Examining commit rINIS3... Raw author string: epriestley Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rPOEMS165b6c54f487c8 Examining commit rPOEMS165b6c54f487... Raw author string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) Raw committer string: epriestley <git@epriestley.com> Phabricator user: epriestley (Evan Priestley ) >>> orbital ~/devtools/phabricator $ ./bin/repository lookup-users rINIH6d24c1aee7741e Examining commit rINIH6d24c1aee774... Raw author string: epriestley <hg@yghe.net> Phabricator user: epriestley (Evan Priestley ) Raw committer string: null >>> orbital ~/devtools/phabricator $ The `reparse.php` output was similar, and all VCSes resolved authors correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1731, T4195 Differential Revision: https://secure.phabricator.com/D7801
2013-12-19 20:05:17 +01:00
'PhabricatorRepositoryManagementLookupUsersWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Add an administrative `bin/repository mark-imported` command Summary: Ref T4068. In some cases like that one, I anticipate a repository not fully importing when a handful of random commits are broken. In the long run we should just deal with that properly, but in the meantime provide an administrative escape hatch so you can mark the repository as imported and get it running normally. The major reason to do this is that Herald, Feed, Harbormaster, etc., won't activate until a repository is "imported". Test Plan: - Tried to mark an imported repository as imported, got an "already imported" message. - Same for not-imported. - Marked a repository not-imported. - Marked a repository imported. - Marked a repository not-imported, then waited for the daemons to mark it imported again automatically. Reviewers: btrahan Reviewed By: btrahan CC: aran, kbrownlees Maniphest Tasks: T4068 Differential Revision: https://secure.phabricator.com/D7514
2013-11-06 20:26:24 +01:00
'PhabricatorRepositoryManagementMarkImportedWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryManagementMirrorWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Record parent relationships when discovering commits Summary: Ref T4455. This adds a `repository_parents` table which stores `<childCommitID, parentCommitID>` relationships. For new commits, it is populated when commits are discovered. For older commits, there's a `bin/repository parents` script to rebuild the data. Right now, there's no UI suggestion that you should run the script. I haven't come up with a super clean way to do this, and this table will only improve performance for now, so it's not important that we get everyone to run the script right away. I'm just leaving it for the moment, and we can figure out how to tell admins to run it later. The ultimate goal is to solve T2683, but solving T4455 gets us some stuff anyway (for example, we can serve `diffusion.commitparentsquery` faster out of this cache). Test Plan: - Used `bin/repository discover` to discover new commits in Git, SVN and Mercurial repositories. - Used `bin/repository parents` to rebuild Git and Mercurial repositories (SVN repos just exit with a message). - Verified that the table appears to be sensible. Reviewers: btrahan Reviewed By: btrahan Subscribers: jhurwitz, epriestley Maniphest Tasks: T4455 Differential Revision: https://secure.phabricator.com/D9044
2014-05-10 21:41:18 +02:00
'PhabricatorRepositoryManagementParentsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce "bin/repository" for repository management Summary: Nothing new or exciting here yet, just moving the random scripts/repositories/ things to bin/repository. Also add `repository list`. (Console stuff comes from D2841.) Test Plan: Ran `repository list`, `repository pull`, `repository discover`, `repository discover --verbose`, `repository help`. Reviewers: jungejason, vrana Reviewed By: vrana CC: aran Differential Revision: https://secure.phabricator.com/D2849
2012-06-25 21:35:37 +02:00
'PhabricatorRepositoryManagementPullWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryManagementRefsWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Separate repository updates from the pull daemon Summary: Ref T4605. Currently, the PullLocal daemon is responsible for two relatively distinct things: - scheduling repository updates; and - actually updating repositories. Move the "actually updating" part into a new `bin/repository update` command, which basically runs the pull, discover, refs and mirror commands. This will let the parent process focus on scheduling in a more understandable way and update multiple repositories at once. It also makes it easier to debug and understand update behavior since the non-scheduling pipeline can be run separately. Test Plan: - Ran `update --trace` on SVN, Mercurial and Git repos. - Ran PullLocal daemon for a while without issues. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4605 Differential Revision: https://secure.phabricator.com/D8780
2014-04-16 22:00:29 +02:00
'PhabricatorRepositoryManagementUpdateWorkflow' => 'PhabricatorRepositoryManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorRepositoryManagementWorkflow' => 'PhabricatorManagementWorkflow',
Basic support for Mercurial in Diffusion Summary: Change import script plus almost all the view stuff. Still some rough edges but this seems to mostly work. Blame is currently unsupported but I think everything else works properly. Test Plan: Imported the hg repository itself. It doesn't immediately seem completely broken. Here are some screens: https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/ https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/ https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/ https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/ All the parsers were able to churn through it without errors. Ran the new "reparse.php" script in various one-commit and repository modes. Browsed/imported some git repos for good measure. NOTE: The hg repository is only 15,000 commits and around 1,000 files. Performance is okay but hg doesn't provide performant, native APIs to get some data efficiently so we have to do some dumb stuff. If some of these interfaces are cripplingly slow or whatever, let me know and we can start bundling some Mercurial extensions with Arcanist. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde, epriestley Differential Revision: 960
2011-09-26 20:07:38 +02:00
'PhabricatorRepositoryMercurialCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Add a Mercurial message parser Summary: See D943, this is the second parse stage. This will mark Differential revisions as "Committed" among other things. Almost all the logic here is shared between VCSes so the implementation itself is straightforward. Test Plan: Parsed all messages for the official Mercurial repository. Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran Reviewed By: Makinde CC: aran, Makinde Differential Revision: 944
2011-09-16 18:37:15 +02:00
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryMirror' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
Separate repository mirroring into an Engine and provide `bin/repository mirror` Summary: Ref T4338. Currently, there's no diagnostic command to execute mirroring (so I can't give users an easy command to run), and it's roughly the last piece of real logic left in the PullLocal daemon. Separate mirroring out, and provide `bin/repository mirror`. Test Plan: - Ran `bin/repository mirror` to mirror a repository. - Ran PullLocalDaemon and verified it also continued mirroring normally. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4338 Differential Revision: https://secure.phabricator.com/D8066
2014-01-25 23:01:58 +01:00
'PhabricatorRepositoryMirrorEngine' => 'PhabricatorRepositoryEngine',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryMirrorQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
move repository arcanist projects over to new phid stuff Summary: also submit casual entry for longest class name award with new query class. Ref T2715 Test Plan: phid.query and saw the right arcanist project Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6586
2013-07-26 23:33:31 +02:00
'PhabricatorRepositoryPHIDTypeArcanistProject' => 'PhabricatorPHIDType',
Use Application PHIDs for commits Summary: Ref T2716. Ref T2715. Move CMIT to use Application PHIDs. Nothing too special here, but I consolidated some code into DiffusionCommitQuery. Depends on D6514. Test Plan: Browsed Diffusion. Browsed Differential/Maniphest with linked commits. Used jump nav; used `phid.lookup` and `phid.query`. Used remarkup for Git and SVN repos. Grepped for PHID_TYPE_CMIT. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T2716 Differential Revision: https://secure.phabricator.com/D6515
2013-07-21 19:57:07 +02:00
'PhabricatorRepositoryPHIDTypeCommit' => 'PhabricatorPHIDType',
Add UI for defining repository mirrors Summary: Ref T4038. This adds everything except the actual pushing part for mirrors. This isn't the most beautiful or sophisticated UI, but I want get the authoritative repositories self-hosted and get users beta-ing hosting as soon as possible. We can do transactions, etc., later on. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4038 Differential Revision: https://secure.phabricator.com/D7632
2013-11-23 00:23:50 +01:00
'PhabricatorRepositoryPHIDTypeMirror' => 'PhabricatorPHIDType',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPHIDTypePushEvent' => 'PhabricatorPHIDType',
Assign PHIDs to PushLogs Summary: Ref T4195. We need these in Herald, since HeraldTranscripts need to refer to a PHID which they acted upon. Test Plan: Ran migration, got PHIDs: mysql> select phid from repository_pushlog limit 3; +--------------------------------+ | phid | +--------------------------------+ | PHID-PSHL-25jnc6cjgzw5rwqgmr7r | | PHID-PSHL-2vrvmtslkrj5yv7nxsv2 | | PHID-PSHL-34x262zkrwoka6mplony | +--------------------------------+ 3 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7780
2013-12-18 00:23:23 +01:00
'PhabricatorRepositoryPHIDTypePushLog' => 'PhabricatorPHIDType',
Use application PHIDs in Repositories Summary: Ref T2715. Move repositories to new app PHIDs. Test Plan: Used `phid.lookup`; `phid.query`; browsed Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6529
2013-07-22 19:45:12 +02:00
'PhabricatorRepositoryPHIDTypeRepository' => 'PhabricatorPHIDType',
Begin making change parsers testable Summary: Ref T4327. There are a bunch of other probably-related tasks too, some linked there. We have some rare/unusual bugs in the change parsers, mostly in Subversion, but it's terrifying to touch them because they're complicated and fragile and have no test coverage. To fix this stuff, I want to make them more testable. In particular, they basically end with this big INSERT right now. Instead, I'm going to make them return objects representing the data to be inserted, then have the common infrastructure do the insert. This gives us two benefits: - Reduced code duplication on the insert; - we can stop before the insert and have unit tests examine the objects. This swaps the Git parser over, but doesn't swap the hg/svn parsers yet. I'll do those separately, the SVN one looks a bit tricky. Test Plan: - Used `scripts/repository/reparse.php` to reparse a Git commit, with `--trace`. Verified it looked the same as before and the SQL that was executed seemed reasonable. - Did the same for `hg` / `svn` commits, to make sure I didn't derp anything. These aren't expected to do anything differently. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7980
2014-01-20 22:12:44 +01:00
'PhabricatorRepositoryParsedChange' => 'Phobject',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorRepositoryPullEngine' => 'PhabricatorRepositoryEngine',
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',
Provide a real object ("PhabricatorRepositoryPushEvent") to represent an entire push transaction Summary: Ref T4677. Currently, we record individual actions in a push as PhabricatorRepositoryPushLogs, but tie them together only loosely with a `transactionKey`. Provide a real PushEvent object, and move some of the denormalized fields to it. This primarily just gives us more robust infrastructure for building, e.g., email about pushes, for T4677, since we can act on real PHIDs rather than passing awkward identifiers around. Test Plan: - Performed migration. - Looked at database for consistency. - Browsed/queried push logs. - Pushed a bunch of stuff. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8615
2014-03-26 03:43:26 +01:00
'PhabricatorRepositoryPushEvent' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorRepositoryPushEventQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Add a basic push log for recording repository push events Summary: Ref T4195. This log serves two purposes: - It's a log, so you can see what happened. Particularly, in Git/Hg, there is no other way to tell: - Who //pushed// a change (vs committed / authored)? - When was a change pushed? - What was the old value of some tag/branch before someone destroyed it? - We can hand these objects off to Herald to implement pre-commit rules. This is a very basic implementation, but gets some data written and has a basic UI for it. Test Plan: {F87339} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4195 Differential Revision: https://secure.phabricator.com/D7705
2013-12-05 20:56:14 +01:00
'PhabricatorRepositoryPushLog' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorRepositoryPushLogQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorRepositoryPushLogSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allow users to receive email about pushes via Herald Summary: Fixes T4677. Implements a "send an email" pre-receive action, which sends push summaries. For use cases where features are often pushed as a large number of commits (e.g., checkpoint commits are retained), using commit emails means users get a ton of email. Instead, this allows you to get an email about a push, which summarizes what changed. Overall, this is basically the same as commit email, but more suitable for some workflows. Test Plan: Wrote some rules, then made a bunch of pushes. Got email like this: {F134929} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4677 Differential Revision: https://secure.phabricator.com/D8618
2014-03-26 18:44:06 +01:00
'PhabricatorRepositoryPushMailWorker' => 'PhabricatorWorker',
'PhabricatorRepositoryPushReplyHandler' => 'PhabricatorMailReplyHandler',
Make Repositories partially policy-aware Summary: Small step toward repository hosting. No user-visible changes. Test Plan: Looked at repositories in Diffusion. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D4227
2012-12-19 20:07:06 +01:00
'PhabricatorRepositoryQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Introduce ref cursors for repository parsing Summary: Ref T4327. I want to make change parsing testable; one thing which is blocking this is that the Git discovery process is still part of `PullLocal` daemon instead of being part of `DiscoveryEngine`. The unit test stuff which I want to use for change parsing relies on `DiscoveryEngine` to discover repositories during unit tests. The major reason git discovery isn't part of `DiscoveryEngine` is that it relies on the messy "autoclose" logic, which we never implemented for Mercurial. Generally, I don't like how autoclose was implemented: it's complicated and gross and too hard to figure out and extend. Instead, I want to do something more similar to what we do for pushes, which is cleaner overall. Basically this means remembering the old branch heads from the last time we parsed a repository, and figuring out what's new by comparing the old and new branch heads. This should give us several advantages: - It should be simpler to understand than the autoclose stuff, which is pretty mind-numbing, at least for me. - It will let us satisfy branch and tag queries cheaply (from the database) instead of having to go to the repository. We could also satisfy some ref-resolve queries from the database. - It should be easier to extend to Mercurial. This implements the basics -- pretty much a table to store the cursors, which we update only for Git for now. Test Plan: - Ran migration. - Ran `bin/repository discover X --trace --verbose` on various repositories with branches and tags, before and after modifying pushes. - Pushed commits to a git repo. - Looked at database tables. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7982
2014-01-16 21:05:30 +01:00
'PhabricatorRepositoryRefCursor' =>
array(
0 => 'PhabricatorRepositoryDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhabricatorRepositoryRefCursorQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorRepositoryRefEngine' => 'PhabricatorRepositoryEngine',
Use ApplicationSearch in Diffusion Summary: Ref T2625. Switches Diffusion to ApplicationSearch. Notes: - Rendering is a bit rough, I'll clean that up next. - Ordering is a bit arbitrary, also coming shortly. Test Plan: Used `/diffusion/` to execute various searches. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2625 Differential Revision: https://secure.phabricator.com/D6917
2013-09-11 00:26:08 +02:00
'PhabricatorRepositorySearchEngine' => 'PhabricatorApplicationSearchEngine',
Add "RepositoryStatusMessage" and detailed information about initilization Summary: `RepositoryStatusMessage` is basically a key/value table associated with a repository that I'm using to let the daemons store the most recent event of a given type, so we can easily show it on the status dashboard. I think this will be a lot easier for users to figure out than digging through logfiles. I'm also going to write the "this needs a pull" status here eventually, for reducing the time lapse between pushes and discovery. - Add storage for these messages. - Have the pull engine populate the INIT phase. I'll do the FETCH phase next. - Update the status readout to show all the various states. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7461
2013-10-31 00:04:19 +01:00
'PhabricatorRepositoryStatusMessage' => 'PhabricatorRepositoryDAO',
Diffusion change parser for SVN. Summary: there is a small possibility this works correctly Test Plan: Reviewers: CC:
2011-03-11 23:13:23 +01:00
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
Increase parseriness of some parsery things. Summary: None of these are parsnips. Test Plan: Reviewers: CC:
2011-03-11 18:34:22 +01:00
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
Add storage for repository symbol tracking Summary: See T315 for an extensive description of this feature. Adds the descibed storage table. Test Plan: Used phpsh to read/write symbol objects. Reviewers: jungejason, nh, tuomaspelkonen, aran Reviewed By: tuomaspelkonen CC: aran, epriestley, tuomaspelkonen Differential Revision: 897
2011-09-05 02:31:16 +02:00
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
Relax the same-origin check in the Git commit discovery daemon Summary: Git accepts either "git@x:/path" or "ssh://git@x.com/path" URIs to mean the exact same thing, which is causing some false positives and confusion, particularly because we sometimes mutate URIs. Since this is just a sanity check, we don't really care about the username, domain or credentials -- matching the paths is good enough. We're just trying to make it hard to shoot yourself in the foot by copy-pasting the same local path into two repositories and forgetting to change one, like I did. :P Relax the check to only verify the paths are the same. Test Plan: - Ran unit tests, which should fully cover things. - Ran commit discovery daemon in debug mode on incorrectly and correctly configured repositories. Reviewers: ajtrichards, jungejason, btrahan Reviewed By: jungejason CC: aran, jungejason Maniphest Tasks: T710 Differential Revision: https://secure.phabricator.com/D1279
2011-12-23 17:11:11 +01:00
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
Begin transacitonalizing repository edits and provide a more sensible edit interface Summary: Ref T2231, T603. Plan of attack here is pretty much: - Built out a new (currently not linked in the UI) edit interface in Diffusion which is transaction-based and has a sensible layout. - Build out a new create interface based on PagedForm which dumps into the new edit interface. - Throw the old stuff away. - Everyone lives happily ever after. Test Plan: {F44163} {F44164} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2231 Differential Revision: https://secure.phabricator.com/D6029
2013-05-24 21:37:42 +02:00
'PhabricatorRepositoryTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorRepositoryTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Move repository URI normalization out of PullLocalDaemon Summary: Ref T4327. Moves us one small step forward toward testable change parsers by separating out this unrelated logic from the PullLocal daemon. We will also probably want to run this logic so we can do remote path lookups to limit the role of Arcanist Projects in the future, which is why I made the URI type (here, only "git") a parameter rather than calling this a `GitURINormalizer` or something. Test Plan: - Ran unit tests. - Ran `repository discover` on a correctly-configured remote repository. - Ran `repository discover` on an incorrectly-configured remote, got an error message. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4327 Differential Revision: https://secure.phabricator.com/D7981
2014-01-16 19:49:03 +01:00
'PhabricatorRepositoryURINormalizer' => 'Phobject',
'PhabricatorRepositoryURINormalizerTestCase' => 'PhabricatorTestCase',
Fix some repository URI handling issues in Git and Mercurial Summary: See <https://github.com/facebook/phabricator/issues/467>. @dctrwatson also ran into an issue where we were trying to `setPass()` a GitURI. - For Git and Mercurial, properly generate credential URIs where relevant. - Don't try to `setPass()` on Git-style URIs. This isn't perfect but should clean things up a bit. Test Plan: Added unit tests. Lots of `grep`. Reviewers: btrahan Reviewed By: btrahan CC: dctrwatson, aran Differential Revision: https://secure.phabricator.com/D7759
2013-12-12 18:45:27 +01:00
'PhabricatorRepositoryURITestCase' => 'PhabricatorTestCase',
Implementation of VCS passwords against user. Summary: This allows users to set their HTTP access passwords via Diffusion interface. Test Plan: Clicked the "Set HTTP Access Password" link, set a password and saw it appear in the DB. Reviewers: #blessed_reviewers, hach-que, btrahan Reviewed By: hach-que CC: Korvin, epriestley, aran, jamesr Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7462
2013-11-01 16:34:11 +01:00
'PhabricatorRepositoryVCSPassword' => 'PhabricatorRepositoryDAO',
Add a robots.txt file to disallow /diffusion/ Summary: Fixes T4610. Open to suggestions, etc., if there's anything I'm missing. Also: - Moves these "system" endpoints into a real application. - Makes `isUnlisted()` work a little more consistently. Test Plan: Accessed `/robots.txt`, `/status/` and `/debug/`. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4610 Differential Revision: https://secure.phabricator.com/D8532
2014-03-14 19:53:17 +01:00
'PhabricatorRobotsController' => 'PhabricatorController',
Add an Amazon S3 storage engine for Phabricator Summary: Implements an S3 storage engine option for Phabricator. Test Plan: - Uploaded files to S3. - Looked at them. - Verified they appeared in S3 using the S3 file browser. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: aran, jungejason Differential Revision: 752
2011-07-31 22:54:58 +02:00
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
Add SMS support Summary: Provides a working SMS implementation with support for Twilio. This version doesn't really retry if we get any gruff at all. Future versions should retry. Test Plan: used bin/sms to send messages and look at them. Reviewers: chad, epriestley Reviewed By: epriestley Subscribers: aurelijus, epriestley, Korvin Maniphest Tasks: T920 Differential Revision: https://secure.phabricator.com/D8930
2014-05-09 21:47:21 +02:00
'PhabricatorSMS' => 'PhabricatorSMSDAO',
'PhabricatorSMSConfigOptions' => 'PhabricatorApplicationConfigOptions',
'PhabricatorSMSDAO' => 'PhabricatorLiskDAO',
'PhabricatorSMSDemultiplexWorker' => 'PhabricatorSMSWorker',
'PhabricatorSMSImplementationTestBlackholeAdapter' => 'PhabricatorSMSImplementationAdapter',
'PhabricatorSMSImplementationTwilioAdapter' => 'PhabricatorSMSImplementationAdapter',
'PhabricatorSMSManagementListOutboundWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementSendTestWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementShowOutboundWorkflow' => 'PhabricatorSMSManagementWorkflow',
'PhabricatorSMSManagementWorkflow' => 'PhabricatorManagementWorkflow',
'PhabricatorSMSSendWorker' => 'PhabricatorSMSWorker',
'PhabricatorSMSWorker' => 'PhabricatorWorker',
Add a "Generate Keypair" option on the SSH Keys panel Summary: Ref T4587. Add an option to automatically generate a keypair, associate the public key, and save the private key. Test Plan: Generated some keypairs. Hit error conditions, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: aran, epriestley Maniphest Tasks: T4587 Differential Revision: https://secure.phabricator.com/D8513
2014-03-13 02:17:11 +01:00
'PhabricatorSSHKeyGenerator' => 'Phobject',
Add an SSH access log Summary: Ref T4107. Ref T4189. This implements an SSH access log, similar to the HTTP access log. Test Plan: [Thu, 05 Dec 2013 13:45:41 -0800] 77841 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 324765 402 232 [Thu, 05 Dec 2013 13:45:48 -0800] 77860 orbital ::1 dweller epriestley epriestley git-receive-pack /diffusion/POEMS/ 0 325634 402 232 Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4107, T4189 Differential Revision: https://secure.phabricator.com/D7719
2013-12-06 02:00:48 +01:00
'PhabricatorSSHLog' => 'Phobject',
Generalize SSH passthru for repository hosting Summary: Ref T2230. In Git, we can determine if a command is read-only or read/write from the command itself, but this isn't the case in Mercurial or SVN. For Mercurial and SVN, we need to proxy the protocol that's coming over the wire, look at each request from the client, and then check if it's a read or a write. To support this, provide a more flexible version of `passthruIO`. The way this will work is: - The SSH IO channel is wrapped in a `ProtocolChannel` which can parse the the incoming stream into message objects. - The `willWriteCallback` will look at those messages and determine if they're reads or writes. - If they're writes, it will check for write permission. - If we're good to go, the message object is converted back into a byte stream and handed to the underlying command. Test Plan: Executed `git clone`, `git clone --depth 3`, `git push` (against no-write repo, got error), `git push` (against valid repo). Reviewers: btrahan Reviewed By: btrahan CC: hach-que, asherkin, aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7551
2013-11-11 21:12:21 +01:00
'PhabricatorSSHPassthruCommand' => 'Phobject',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorSSHWorkflow' => 'PhabricatorManagementWorkflow',
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',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchApplicationSearchEngine' => 'PhabricatorApplicationSearchEngine',
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',
Move even more rendering into SearchEngine Summary: Ref T4986. I think this is the last of the easy ones, there are about 10 not-quite-so-trivial ones left. Test Plan: - Viewed app results. - Created panels. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9025
2014-05-09 21:28:02 +02:00
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
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',
Partially use ApplicationSearch in main search Summary: Ref T4365. Primary search currently uses `PhabricatorSearchQuery` for storage, which is pretty much the same as `PhabricatorSavedQuery`, except that it's old and not used anywhere else anymore. Maniphest used to also use this table, but no longer does after Septmeber, 2013. We need to retain the class so the migration can work. This introduces `PhabricatorSearchApplicationSearchEngine` and `PhabricatorSearchDocumentQuery`, but they're both stubs that I just needed for technical reasons and/or to pass lint. The next couple patches will move logic into them and use ApplicationSearch properly. Test Plan: - Searched for stuff. - Searched for stuff with filters. - Searched for fulltext in Maniphest. - Grepped for `PhabricatorSearchQuery`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4365 Differential Revision: https://secure.phabricator.com/D8120
2014-02-03 21:51:08 +01:00
'PhabricatorSearchDocumentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rought cut of search. Summary: Botched this pretty badly in git so we'll see how much I broke. :/ Test Plan: Reviewers: CC:
2011-02-15 00:34:20 +01:00
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
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',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorSearchManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
Perform search indexing in the worker queue and respect `bin/search index --background` Summary: Fixes T3857. Earlier work made this trivial and just left product questions, which I've answered by requiring the daemons to run on reasonable installs. Test Plan: Ran `bin/search index` and `bin/search index --background`. Observed indexes write in the former case and tasks queue in the latter case. Commented with a unique string on a revision and searched for it a moment later, got exactly one result (that revision), verifying that reindexing works correctly. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7966
2014-01-14 22:22:56 +01:00
'PhabricatorSearchWorker' => 'PhabricatorWorker',
Add the "Security" config group options. Summary: Added all the "Security" group options listed in T2255. Test Plan: - Looked at all the options. - Tested validation on `security.alternate-file-domain` Reviewers: epriestley, btrahan Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T2255 Differential Revision: https://secure.phabricator.com/D4334
2013-01-03 14:45:23 +01:00
'PhabricatorSecurityConfigOptions' => 'PhabricatorApplicationConfigOptions',
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',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSettingsAddEmailAction' => 'PhabricatorSystemAction',
Move Settings to a separate directory Summary: We currently have two relatively distinct applications, "People" and "Settings", living in /people/. Move settings to its own directory. This renames a couple of classes but makes no real code changes. Test Plan: Browsed /settings/, changed some settings. Reviewers: btrahan, vrana Reviewed By: btrahan CC: aran Maniphest Tasks: T1569, T631 Differential Revision: https://secure.phabricator.com/D3256
2012-08-13 21:37:18 +02:00
'PhabricatorSettingsAdjustController' => 'PhabricatorController',
'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',
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorSettingsPanelActivity' => '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
'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',
Improve usability of DarkConsole settings Summary: Fixes T3632. Cleans up a bunch of DarkConsole stuff: - The config setting had out-of-date instructions. Modernize the instructions. - The setting was sort of hidden under "Display Preferences". Move it to a new "Developer Preferences". - The setting magically appeared if DarkConsole was enabled on the install. Instead, always show it but explain why it isn't availalbe. - When the user enables the console, also force it to actually be shown. - Call out instructions about use of the "`" key more clearly. Test Plan: Viewed config setting. Viewed settings panel. Changed setting. Enabling the setting showed DarkConsole. Reviewers: garoevans, chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T3632 Differential Revision: https://secure.phabricator.com/D6594
2013-07-28 05:18:58 +02:00
'PhabricatorSettingsPanelDeveloperPreferences' => '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',
Move all account link / unlink to new registration flow Summary: Ref T1536. Currently, we have separate panels for each link/unlink and separate controllers for OAuth vs LDAP. Instead, provide a single "External Accounts" panel which shows all linked accounts and allows you to link/unlink more easily. Move link/unlink over to a full externalaccount-based workflow. Test Plan: - Linked and unlinked OAuth accounts. - Linked and unlinked LDAP accounts. - Registered new accounts. - Exercised most/all of the error cases. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, mbishopim3 Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6189
2013-06-17 15:12:45 +02:00
'PhabricatorSettingsPanelExternalAccounts' => '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',
Add multi-factor auth and TOTP support Summary: Ref T4398. This is still pretty rough and isn't exposed in the UI yet, but basically works. Some missing features / areas for improvement: - Rate limiting attempts (see TODO). - Marking tokens used after they're used once (see TODO), maybe. I can't think of ways an attacker could capture a token without also capturing a session, offhand. - Actually turning this on (see TODO). - This workflow is pretty wordy. It would be nice to calm it down a bit. - But also add more help/context to help users figure out what's going on here, I think it's not very obvious if you don't already know what "TOTP" is. - Add admin tool to strip auth factors off an account ("Help, I lost my phone and can't log in!"). - Add admin tool to show users who don't have multi-factor auth? (so you can pester them) - Generate QR codes to make the transfer process easier (they're fairly complicated). - Make the "entering hi-sec" workflow actually check for auth factors and use them correctly. - Turn this on so users can use it. - Adding SMS as an option would be nice eventually. - Adding "password" as an option, maybe? TOTP feels fairly good to me. I'll post a couple of screens... Test Plan: - Added TOTP token with Google Authenticator. - Added TOTP token with Authy. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8875
2014-04-28 18:27:11 +02:00
'PhabricatorSettingsPanelMultiFactor' => '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
'PhabricatorSettingsPanelPassword' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelSSHKeys' => 'PhabricatorSettingsPanel',
'PhabricatorSettingsPanelSearchPreferences' => 'PhabricatorSettingsPanel',
Add an "active login sessions" table to Settings Summary: Ref T4310. Ref T3720. Partly, this makes it easier for users to understand login sessions. Partly, it makes it easier for me to make changes to login sessions for T4310 / T3720 without messing anything up. Test Plan: {F101512} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3720, T4310 Differential Revision: https://secure.phabricator.com/D7954
2014-01-14 20:05:45 +01:00
'PhabricatorSettingsPanelSessions' => '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',
Version the Aphlict notification server and prompt users to upgrade if they're out of date Summary: Ref T4324. Add some version information to the server status output, and setup checks to test for an unreachable or out-of-date server. Test Plan: - With server down, hit reasonable setup check. - With server up and at a bad version, hit reasonable setup check. - Viewed `/notification/status/`. - The CSS thing fixes this: {F114445} Reviewers: btrahan, chad Reviewed By: chad CC: chad, aran Maniphest Tasks: T4324 Differential Revision: https://secure.phabricator.com/D8251
2014-02-18 00:59:39 +01:00
'PhabricatorSetupCheckAphlict' => 'PhabricatorSetupCheck',
Add first-time-setup registration flow Summary: Ref T1536. Currently, when you install Phabricator you're dumped on the login screen and have to consult the documentation to learn about `bin/accountadmin`. Instead, detect that an install is running first-time setup: - It has no configured providers; and - it has no user accounts. We can safely deduce that such an install isn't configured yet, and let the user create an admin account from the web UI. After they login, we raise a setup issue and lead them to configure authentication. (This could probably use some UI and copy tweaks.) Test Plan: {F46738} {F46739} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1536 Differential Revision: https://secure.phabricator.com/D6228
2013-06-20 01:28:48 +02:00
'PhabricatorSetupCheckAuth' => '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',
Warn if daemons are not running Summary: Currently, we try to mostly-kind-of-work if daemons aren't running (for example, we send mail in-process). I want to stop doing this. A major motivator is that `metamta.send-immediately` is confusing for a lot of users and frequently the cause of performance problems. Increasingly, functionality of applications depends on the daemons (Harbormaster, Drydock, Nuance all require daemons to do anything at all). They're also fairly stable/robust/well-tested and no reasonable install should be running without them. This will let us simplify or remove some flags (like `metamta.send-immediately`) and simplify some other processes like search indexing. Test Plan: Stopped daemons, loaded warnings, saw daemon warning. Started daemons, reloade, no warning. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3857 Differential Revision: https://secure.phabricator.com/D7964
2014-01-14 22:22:40 +01:00
'PhabricatorSetupCheckDaemons' => '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',
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',
Raise a setup warning for missing or invalid local repository directory Summary: I'm planning to add more detailed info to Diffusion itself, but catch the big issue here. Test Plan: Hit config issue locally, then resolved it. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7439
2013-10-30 21:07:09 +01:00
'PhabricatorSetupCheckRepositories' => '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',
Provide application and object level policy controls in Slowvote Summary: Ref T603. Gives the create/edit interface a policy control, and adds an application-level default. Test Plan: Created and edited polls. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7321
2013-10-16 19:36:00 +02:00
'PhabricatorSlowvoteCapabilityDefaultView' => 'PhabricatorPolicyCapability',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteChoice' => 'PhabricatorSlowvoteDAO',
Ability to close poll Summary: Fixes T3566 List of poll actions should include ability to close an open poll or reopen a closed poll. Test Plan: Poll author should be able to close/reopen poll. Non-author should get policy screen when attempting to close/reopen poll. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Maniphest Tasks: T3566 Differential Revision: https://secure.phabricator.com/D8846
2014-04-24 21:00:31 +02:00
'PhabricatorSlowvoteCloseController' => 'PhabricatorSlowvoteController',
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
'PhabricatorSlowvoteComment' => 'PhabricatorSlowvoteDAO',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteCommentController' => 'PhabricatorSlowvoteController',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteController' => 'PhabricatorController',
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
Make most slowvote fields edit transactionally Summary: No support for responses yet, since they're more complicated, but put everything else on the transactions plan. This also prepares polls for editability, shortly. Test Plan: {F50205} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6460
2013-07-15 19:50:38 +02:00
'PhabricatorSlowvoteEditController' => 'PhabricatorSlowvoteController',
Restore Slowvote commenting with ApplicationTransactions Summary: Now it works like everything else does. Test Plan: {F50168} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6455
2013-07-15 13:45:43 +02:00
'PhabricatorSlowvoteEditor' => 'PhabricatorApplicationTransactionEditor',
Move Slowvote rendering into SearchEngine Summary: Ref T4986. This adds a bit of structure for handles, since we used to have Controller utilities but no longer do. Hopefully these will start going faster soon... Test Plan: - Checked feed for collateral damage. - Checked slowvote for collateral damage. - Made a slowvote panel. {F151550} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9010
2014-05-08 17:40:59 +02:00
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
Provide basic infrastructure for moving PHIDs, Handles and Object Names to applications Summary: See discussion in T2715. Currently, PHIDs are all hard coded in the PHID application. In the long run, we need to move them out into actual applications. A specific immediate issue is Releeph, which uses a very very old and very broken mechanism to inject PHIDs in a way that only sort of works. Moving forward, every PHID type will be provided by a `PhabricatorPHIDType` subclass, which will manage loading it, etc. This also moves toward cleaning up the "load objects by name" (where "name" means something like `D12`) code, which is an //enormous// mess and spread across at least 4-5 callsites. Test Plan: Used `phid.lookup` and `phid.query` to load Slowvotes. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6502
2013-07-21 15:34:21 +02:00
'PhabricatorSlowvotePHIDTypePoll' => 'PhabricatorPHIDType',
Add PhabricatorSlowvoteQuery Summary: Ref T603. Ref T2625. Start pushing Slowvote (the greatest app of all time) into the modern era. Test Plan: Looked at vote detail. Used `V1` and `{V1}` embeds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6444
2013-07-13 19:41:30 +02:00
'PhabricatorSlowvotePoll' =>
array(
0 => 'PhabricatorSlowvoteDAO',
1 => 'PhabricatorPolicyInterface',
Make most slowvote fields edit transactionally Summary: No support for responses yet, since they're more complicated, but put everything else on the transactions plan. This also prepares polls for editability, shortly. Test Plan: {F50205} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6460
2013-07-15 19:50:38 +02:00
2 => 'PhabricatorSubscribableInterface',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => 'PhabricatorTokenReceiverInterface',
Add PhabricatorSlowvoteQuery Summary: Ref T603. Ref T2625. Start pushing Slowvote (the greatest app of all time) into the modern era. Test Plan: Looked at vote detail. Used `V1` and `{V1}` embeds. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6444
2013-07-13 19:41:30 +02:00
),
Port the "Slowvote" application Summary: Port slowvote. This has some style/layout roughness but gets us most of the way there. I'll followup to fix some of the markup issues. Test Plan: Created and voted in several different kinds of poll. Reviewed By: codeblock Reviewers: codeblock, tomo, jungejason, aran, tuomaspelkonen Commenters: aran, jungejason CC: aran, codeblock, jungejason, epriestley Differential Revision: 613
2011-07-08 20:13:11 +02:00
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
Use ApplicationSearch in Slowvote Summary: Ref T2625. Ref T603. Make the vote list policy-aware, mobile-friendly, and use ApplicationSearch. Test Plan: {F50022} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2625 Differential Revision: https://secure.phabricator.com/D6445
2013-07-13 19:41:49 +02:00
'PhabricatorSlowvoteQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhabricatorSlowvoteSearchEngine' => 'PhabricatorApplicationSearchEngine',
Migrate Slowvote comments to ApplicationTransactions Summary: Move comments from the old table to ApplicationTransactions. Patch dances around which objects it uses since I intend to delete the comment table. NOTE: This temporarily disables comment writes. I'll restore them shortly. Test Plan: {F50166} Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6454
2013-07-15 13:20:10 +02:00
'PhabricatorSlowvoteTransaction' => 'PhabricatorApplicationTransaction',
'PhabricatorSlowvoteTransactionComment' => 'PhabricatorApplicationTransactionComment',
'PhabricatorSlowvoteTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Embed slowvotes have basic interaction Summary: User can now vote through embed slowvote Test Plan: Voted'n stuff Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, chad, AnhNhan Maniphest Tasks: T2883 Differential Revision: https://secure.phabricator.com/D5743
2013-05-04 00:48:59 +02:00
'PhabricatorSlowvoteVoteController' => 'PhabricatorSlowvoteController',
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',
Implement standard field "bool" type Summary: Depends on D7005. Implements the existing "bool" type. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7006
2013-09-17 01:03:51 +02:00
'PhabricatorStandardCustomFieldBool' => 'PhabricatorStandardCustomField',
Implement a "credential" standard custom field Summary: Ref T4590. Ref T1049. This is primarily intended to support HTTP auth in Harbormaster. Test Plan: Added a field, edited it, etc. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4590, T1049 Differential Revision: https://secure.phabricator.com/D8607
2014-03-26 00:13:27 +01:00
'PhabricatorStandardCustomFieldCredential' => 'PhabricatorStandardCustomField',
Add a "date" standard custom field Summary: See previous revisions. As maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7009
2013-09-17 01:04:31 +02:00
'PhabricatorStandardCustomFieldDate' => 'PhabricatorStandardCustomField',
Add a "Header" standard custom field Summary: Ref T418. This is the last of the Maniphest field types, although I have a few more capabilities/options to port over. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T418 Differential Revision: https://secure.phabricator.com/D7018
2013-09-17 23:22:04 +02:00
'PhabricatorStandardCustomFieldHeader' => 'PhabricatorStandardCustomField',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldInt' => 'PhabricatorStandardCustomField',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldPHIDs' => 'PhabricatorStandardCustomField',
Implement a "remarkup" standard field type Summary: See D7006, etc. This one's easy since exposing it to ApplicationSearch doesn't make much sense. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7008
2013-09-17 01:04:18 +02:00
'PhabricatorStandardCustomFieldRemarkup' => 'PhabricatorStandardCustomField',
Implement a "select" standard custom field type Summary: See D7006, etc. Brings this from Maniphest. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7007
2013-09-17 01:04:08 +02:00
'PhabricatorStandardCustomFieldSelect' => 'PhabricatorStandardCustomField',
Use classes to define standard field types and implement an "int" type Summary: Currently, `ManiphestAuxiliaryFieldDefaultSpecification` uses about a dozen giant `switch` statements to implement stadard field types (int, string, date, bool, select, user, remarkup, etc). This is: - pretty gross; - not extensible; and - doesn't really let us share that much code. I got about halfway through porting a similar implementation into StandardField but I wasn't thrilled with it. Subclass StandardField instead to implement custom field types. Test Plan: Added an "int" custom field, verified it had integer semantics and indexed into the integer index. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7005
2013-09-17 01:03:24 +02:00
'PhabricatorStandardCustomFieldText' => 'PhabricatorStandardCustomField',
Add "user" and "users" standard custom fields Summary: These end up a little weird with subclassing instead of `switch`, but some day we could alias them to one another or something I guess. If I'm feeling brave, I might get rid of the "user" variant when I migrate Maniphest custom field specs, and turn it into "users, limit = 1" or something like that. Test Plan: See screenshots. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7010
2013-09-17 01:04:46 +02:00
'PhabricatorStandardCustomFieldUsers' => 'PhabricatorStandardCustomFieldPHIDs',
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',
Move "scripts/sql/probe.php" to "bin/storage probe" Summary: This makes it namespace/database/connection aware and a little easier to find. Also use pht() / PhutilConsole. Test Plan: Ran `bin/storage probe`. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6341
2013-07-03 01:34:17 +02:00
'PhabricatorStorageManagementProbeWorkflow' => 'PhabricatorStorageManagementWorkflow',
Make SQL patch management DAG-based and provide namespace support Summary: This addresses three issues with the current patch management system: # Two people developing at the same time often pick the same SQL patch number, and then have to go rename it. The system catches this, but it's silly. # Second/third-party developers can't use the same system to manage auxiliary storage they may want to add. # There's no way to build mock databases for unit tests that need to do reads. To resolve these things, you can now name your patches whatever you want and conflicts are just merge conflicts, which are less of a pain to fix than filename conflicts. Dependencies are now a DAG, with implicit dependencies created on the prior patch if no dependencies are specified. Developers can add new concrete subclasses of `PhabricatorSQLPatchList` to add storage management, and define the dependency branchpoint of their patches so they apply in the correct order (although, generally, they should not depend on the mainline patches, presumably). The commands `storage upgrade --namespace test1234` and `storage destroy --namespace test1234` will allow unit tests to build and destroy MySQL storage. A "quickstart" mode allows an upgrade from scratch in ~1200ms. Destruction takes about 200ms. These seem like fairily reasonable costs to actually use in tests. Building from scratch patch-by-patch takes about 6000ms. Test Plan: - Created new databases from scratch with and without quickstart in a separate test namespace. Pointed the webapp at the test namespaces, browsed around, everything looked good. - Compared quickstart and no-quickstart dump states, they're identical except for mysqldump timestamps and a few similar things. - Upgraded a legacy database to the new storage format. - Destroyed / dumped storage. Reviewers: edward, vrana, btrahan, jungejason Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T140, T345 Differential Revision: https://secure.phabricator.com/D2323
2012-04-30 16:54:00 +02:00
'PhabricatorStorageManagementStatusWorkflow' => 'PhabricatorStorageManagementWorkflow',
'PhabricatorStorageManagementUpgradeWorkflow' => 'PhabricatorStorageManagementWorkflow',
Extend all "ManagementWorkflow" classes from a base class Summary: Ref T2015. Not directly related to Drydock, but I've wanted to do this for a bit. Introduce a common base class for all the workflows in the scripts in `bin/*`. This slightly reduces code duplication by moving `isExecutable()` to the base, but also provides `getViewer()`. This is a little nicer than `PhabricatorUser::getOmnipotentUser()` and gives us a layer of indirection if we ever want to introduce more general viewer mechanisms in scripts. Test Plan: Lint; ran some of the scripts. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2015 Differential Revision: https://secure.phabricator.com/D7838
2013-12-27 22:15:40 +01:00
'PhabricatorStorageManagementWorkflow' => 'PhabricatorManagementWorkflow',
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',
Subscriptions - make a dialog for massive subscription lists Summary: Ref T4430. This just deploys it on the property lists. (Help on how to do translations better? I tried a more traditional pht('%s, %s, %s, and %d other(s)') but I think the string lookup assumes the %d comes as the second param or something?) Test Plan: Made a Maniphest Task with a hojillion subscribers and noted the working dialogue. Also made a Pholio Mock with lots of subscribers and it worked. Reviewers: epriestley Reviewed By: epriestley Subscribers: aran, epriestley, Korvin, chad Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8525
2014-03-14 19:22:00 +01:00
'PhabricatorSubscriptionsListController' => 'PhabricatorController',
Transactions - add "and X others" dialog support to application transactions Summary: Fixes T4430. Basically does a little code massage from the new stuff in D8525 and application transactions to get this working. Adds a new controller to the subscriptions app to make rendering these pretty easy peasy. Test Plan: Used my test task in D8525 to verify both add and rem versions of these dialogs worked correctly. Reviewers: epriestley Reviewed By: epriestley Subscribers: epriestley, chad, Korvin Maniphest Tasks: T4430 Differential Revision: https://secure.phabricator.com/D8540
2014-03-14 22:27:45 +01:00
'PhabricatorSubscriptionsTransactionController' => 'PhabricatorController',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorSubscriptionsUIEventListener' => 'PhabricatorEventListener',
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',
Add semi-generic rate limiting infrastructure Summary: This adds a system which basically keeps a record of recent actions, who took them, and how many "points" they were worth, like: epriestley email.add 1 1233989813 epriestley email.add 1 1234298239 epriestley email.add 1 1238293981 We can use this to rate-limit actions by examining how many actions the user has taken in the past hour (i.e., their total score) and comparing that to an allowed limit. One major thing I want to use this for is to limit the amount of error email we'll send to an email address. A big concern I have with sending more error email is that we'll end up in loops. We have some protections against this in headers already, but hard-limiting the system so it won't send more than a few errors to a particular address per hour should provide a reasonable secondary layer of protection. This use case (where the "actor" needs to be an email address) is why the table uses strings + hashes instead of PHIDs. For external users, it might be appropriate to rate limit by cookies or IPs, too. To prove it works, I rate limited adding email addresses. This is a very, very low-risk security thing where a user with an account can enumerate addresses (by checking if they get an error) and sort of spam/annoy people (by adding their address over and over again). Limiting them to 6 actions / hour should satisfy all real users while preventing these behaviors. Test Plan: This dialog is uggos but I'll fix that in a sec: {F137406} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8683
2014-04-03 20:22:38 +02:00
'PhabricatorSystemActionEngine' => 'Phobject',
'PhabricatorSystemActionGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorSystemActionLog' => 'PhabricatorSystemDAO',
'PhabricatorSystemActionRateLimitException' => 'Exception',
'PhabricatorSystemDAO' => 'PhabricatorLiskDAO',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
'PhabricatorSystemDestructionGarbageCollector' => 'PhabricatorGarbageCollector',
'PhabricatorSystemDestructionLog' => 'PhabricatorSystemDAO',
'PhabricatorSystemRemoveDestroyWorkflow' => 'PhabricatorSystemRemoveWorkflow',
'PhabricatorSystemRemoveLogWorkflow' => 'PhabricatorSystemRemoveWorkflow',
'PhabricatorSystemRemoveWorkflow' => 'PhabricatorManagementWorkflow',
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',
Fix controller-level access rules Summary: Ref T603. I had to partially revert this earlier because it accidentally blocked access to Conduit and File data for installs without "policy.allow-public", since the applications are available to "all users" but some endpoints actually need to be available even when not logged in. This readjusts the gating in the controller to properly apply application visibility restrictions, and then adds a giant pile of unit test coverage to make sure it sticks and all the weird cases are covered. Test Plan: - Added and executed unit tests. - Executed most of the tests manually, by using logged in / admin / public / disabled users. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603 Differential Revision: https://secure.phabricator.com/D7211
2013-10-04 04:05:47 +02:00
'PhabricatorTestController' => 'PhabricatorController',
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',
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',
Enrich "gave a token" feed story Summary: Name the token which was given in the feed story. Test Plan: Gave/rescinded tokens. Looked at a feed story. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D7110
2013-09-25 02:00:31 +02:00
'PhabricatorTokenPHIDTypeToken' => 'PhabricatorPHIDType',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhabricatorTokenUIEventListener' => 'PhabricatorEventListener',
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',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadCompositeDatasource' => 'PhabricatorTypeaheadDatasource',
'PhabricatorTypeaheadDatasource' => 'Phobject',
Typeaheads
2011-01-25 22:48:05 +01:00
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
Begin modularizing typeahead sources Summary: Ref T4420. This sets up the basics for modular typeahead sources. Basically, the huge `switch()` is just replaced with class-based runtime dispatch. The only clever bit I'm doing here is with `CompositeDatasource`, which pretty much just combines the results from several other datasources. We can use this to implement some of the weird cases where we need multiple types of results, although I think I can entirely eliminate many of them entirely. It also makes top-level implementation simpler, since more logic can go inside the sources. Sources are also application-aware, will be responsible for placeholder text, and have a slightly nicer debug view. Test Plan: {F112859} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T4420 Differential Revision: https://secure.phabricator.com/D8228
2014-02-14 19:23:25 +01:00
'PhabricatorTypeaheadModularDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
'PhabricatorTypeaheadMonogramDatasource' => 'PhabricatorTypeaheadDatasource',
'PhabricatorTypeaheadRuntimeCompositeDatasource' => 'PhabricatorTypeaheadCompositeDatasource',
Add UI for choosing header color Summary: See D7731. Fixes T4194. Test Plan: {F88020} Reviewers: chad, btrahan Reviewed By: chad CC: aran, mbishopim3 Maniphest Tasks: T4194 Differential Revision: https://secure.phabricator.com/D7740
2013-12-07 19:46:09 +01:00
'PhabricatorUIConfigOptions' => 'PhabricatorApplicationConfigOptions',
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 PHUIStatusListView Summary: For Diffusion's auditors list, and Differential's reviewers list (eventually). An inline option might make more sense in Differential, but I want to use this in Diffusion first, and we need more information there. Test Plan: {F51424} Reviewers: chad, btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D6559
2013-07-24 23:13:22 +02:00
'PhabricatorUIStatusExample' => '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',
Implement bin/remove, for structured destruction of objects Summary: Ref T4749. Ref T3265. Ref T4909. Several goals here: - Move user destruction to the CLI to limit the power of rogue admins. - Start consolidating all "destroy named object" scripts into a single UI, to make it easier to know how to destroy things. - Structure object destruction so we can do a better and more automatic job of cleaning up transactions, edges, search indexes, etc. - Log when we destroy objects so there's a record if data goes missing. Test Plan: Used `bin/remove destroy` to destroy several users. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3265, T4749, T4909 Differential Revision: https://secure.phabricator.com/D8940
2014-05-02 03:23:31 +02:00
4 => 'PhabricatorDestructableInterface',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
),
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserBlurbField' => 'PhabricatorUserCustomField',
'PhabricatorUserConfigOptions' => 'PhabricatorApplicationConfigOptions',
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorUserConfiguredCustomField' =>
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
array(
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
0 => 'PhabricatorUserCustomField',
1 => 'PhabricatorStandardCustomFieldInterface',
Allow user override translation and implement PhutilPerson Test Plan: Altered database. Wrote a custom translation and selected it in preferences. Verified that the text is custom translated. Set language back to default. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T1139 Differential Revision: https://secure.phabricator.com/D2757
2012-06-15 03:08:06 +02:00
),
Support configuration-driven custom fields Summary: Ref T1702. Ref T3718. There are a couple of things going on here: **PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller: foreach ($fields as $field) { // do some junk } Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`. **PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc). **Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it. The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes). **Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs. Test Plan: {F54240} {F54241} {F54242} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T1702, T1703, T3718 Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 17:10:16 +02:00
'PhabricatorUserConfiguredCustomFieldStorage' => 'PhabricatorCustomFieldStorage',
'PhabricatorUserCustomField' => 'PhabricatorCustomField',
Integrate ApplicationSearch with CustomField Summary: Ref T2625. Ref T3794. Ref T418. Ref T1703. This is a more general version of D5278. It expands CustomField support to include real integration with ApplicationSearch. Broadly, custom fields may elect to: - build indicies when objects are updated; - populate ApplicationSearch forms with new controls; - read inputs entered into those controls out of the request; and - apply constraints to search queries. Some utility/helper stuff is provided to make this easier. This part could be cleaner, but seems reasonable for a first cut. In particular, the Query and SearchEngine must manually call all the hooks right now instead of everything happening magically. I think that's fine for the moment; they're pretty easy to get right. Test Plan: I added a new searchable "Company" field to People: {F58229} This also cleaned up the disable/reorder view a little bit: {F58230} As it did before, this field appears on the edit screen: {F58231} However, because it has `search`, it also appears on the search screen: {F58232} When queried, it returns the expected results: {F58233} And the actually good bit of all this is that the query can take advantage of indexes: mysql> explain SELECT * FROM `user` user JOIN `user_customfieldstringindex` `appsearch_0` ON `appsearch_0`.objectPHID = user.phid AND `appsearch_0`.indexKey = 'mk3Ndy476ge6' AND `appsearch_0`.indexValue IN ('phacility') ORDER BY user.id DESC LIMIT 101; +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ | 1 | SIMPLE | appsearch_0 | ref | key_join,key_find | key_find | 232 | const,const | 1 | Using where; Using temporary; Using filesort | | 1 | SIMPLE | user | eq_ref | phid | phid | 194 | phabricator2_user.appsearch_0.objectPHID | 1 | | +----+-------------+-------------+--------+-------------------+----------+---------+------------------------------------------+------+----------------------------------------------+ 2 rows in set (0.00 sec) Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T418, T1703, T2625, T3794 Differential Revision: https://secure.phabricator.com/D6992
2013-09-16 22:44:34 +02:00
'PhabricatorUserCustomFieldNumericIndex' => 'PhabricatorCustomFieldNumericIndexStorage',
'PhabricatorUserCustomFieldStringIndex' => 'PhabricatorCustomFieldStringIndexStorage',
Basic user/account tool.
2011-01-24 03:09:16 +01:00
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
If users are on the email to Phabricator, do not send them the Phabricator reply. Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email. Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected. Reviewers: epriestley, vrana Reviewed By: vrana CC: aran, Korvin, vrana Maniphest Tasks: T1676 Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 19:18:23 +02:00
'PhabricatorUserEditor' => 'PhabricatorEditor',
Disallow email addresses which will overflow MySQL storage Summary: Via HackerOne. An attacker can bypass `auth.email-domains` by registering with an email like: aaaaa...aaaaa@evil.com@company.com We'll validate the full string, then insert it into the database where it will be truncated, removing the `@company.com` part. Then we'll send an email to `@evil.com`. Instead, reject email addresses which won't fit in the table. `STRICT_ALL_TABLES` stops this attack, I'm going to add a setup warning encouraging it. Test Plan: - Set `auth.email-domains` to `@company.com`. - Registered with `aaa...aaa@evil.com@company.com`. Previously this worked, now it is rejected. - Did a valid registration. - Tried to add `aaa...aaaa@evil.com@company.com` as an email address. Previously this worked, now it is rejected. - Did a valid email add. - Added and executed unit tests. Reviewers: btrahan, arice Reviewed By: arice CC: aran, chad Differential Revision: https://secure.phabricator.com/D8308
2014-02-23 19:19:35 +01:00
'PhabricatorUserEditorTestCase' => 'PhabricatorTestCase',
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
'PhabricatorUserEmail' => 'PhabricatorUserDAO',
Add rough validation on email addresses Summary: Put a very rough filter on what we'll accept as an email address. We can expand this if anyone is actually using local delivery or other weird things. This is mostly to avoid a theoretical case where some input is parsed differently by `PhutilAddressParser` and the actual mail adapter, in some subtle hypothetical way. This should give us only "reasonable" email addresses which parsers would be hard-pressed to trip up on. Test Plan: Added and executed unit tests. Tried to add silly emails. Added valid emails. Reviewers: btrahan, arice Reviewed By: arice CC: arice, chad, aran Differential Revision: https://secure.phabricator.com/D8320
2014-02-24 02:31:46 +01:00
'PhabricatorUserEmailTestCase' => 'PhabricatorTestCase',
Modernize user activity logs (ApplicationSearch, policies) Summary: Ref T4398. Ref T4842. I want to let users review their own account activity, partly as a general security measure and partly to make some of the multi-factor stuff easier to build and debug. To support this, implement modern policies and application search. I also removed the "old" and "new" columns from this output, since they had limited utility and revealed email addresses to administrators for some actions. We don't let administrators access email addresses from other UIs, and the value of doing so here seems very small. Test Plan: Used interface to issue a bunch of queries against user logs, got reasonable/expected results. Reviewers: btrahan Reviewed By: btrahan Subscribers: keir, epriestley Maniphest Tasks: T4842, T4398 Differential Revision: https://secure.phabricator.com/D8856
2014-04-28 02:31:35 +02:00
'PhabricatorUserLog' =>
array(
0 => 'PhabricatorUserDAO',
1 => 'PhabricatorPolicyInterface',
),
Let users review their own account activity logs Summary: Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are: - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver. - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it). - Improve user confidence in security by making logging more apparent and accessible. Minor corresponding changes: - Entering and exiting hisec mode is now logged. - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge. Test Plan: - Viewed new panel. - Viewed old UI. - Entered/exited hisec and got prompted. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4398 Differential Revision: https://secure.phabricator.com/D8871
2014-04-28 02:32:09 +02:00
'PhabricatorUserLogView' => 'AphrontView',
User preferences ported from tools Summary: Internal tools, e.g., differential and diffusion have user defined preferences for monospaced font and the option for showing either the name of the tool or the glyph of the tool in the title. These preferences were ported to phabricator. These preferences can be modified in /preferences/ and they both affect diffusion and differential at the moment. Test Plan: * Created an empty database * Loaded /preferences/ and modified the monospaced font and clicked save * Confirmed that the same page was loaded with the message that preferences have been saved and that the example text used the user defined font * in /preferences/ changed the option to show tool names as plain text and clicked save * Confirmed that the same page was loaded with '[Preferences]' in the title instead of a glyph * These same tests were also executed for differential and diffusion Reviewers: epriestley CC: jungejason Differential Revision: 91
2011-03-31 04:21:09 +02:00
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
Slightly more sophisticated profiles. Summary: Test Plan: Reviewers: CC:
2011-02-20 03:28:41 +01:00
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
Add ApplicationTransactions/CustomField based user profile editor Summary: Adds a profile edit controller (with just one field and on links to it) that uses ApplicationTransactions and CustomField. {F45617} My plan is to move the other profile fields to this interface and get rid of Settings -> Profile. Basically, these will be "settings": - Sex - Language - Timezone These will be "profile": - Real Name - Title - Blurb - Profile Image (but I'm going to put this on a separate UI) - Other custom fields Test Plan: Edited my realname using the new interface. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6152
2013-06-07 18:55:55 +02:00
'PhabricatorUserProfileEditor' => 'PhabricatorApplicationTransactionEditor',
'PhabricatorUserRealNameField' => 'PhabricatorUserCustomField',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserRolesField' => 'PhabricatorUserCustomField',
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',
Merge profile "About" into main profile and simplify some custom field stuff Summary: Ref T1703. Drive "user since" with a custom field and make the other fields render into a property list. Users can make their profiles a little more personal/obnoxious now. Also delete a bunch of code. Test Plan: {F49415} Reviewers: chad, btrahan Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6401
2013-07-10 14:09:59 +02:00
'PhabricatorUserSinceField' => 'PhabricatorUserCustomField',
Move roles and status into properties on profile view Summary: See discussion in D6403. Test Plan: {F49488} Reviewers: chad, btrahan Reviewed By: chad CC: aran Differential Revision: https://secure.phabricator.com/D6409
2013-07-10 21:34:09 +02:00
'PhabricatorUserStatusField' => 'PhabricatorUserCustomField',
Unify logic for username validation Summary: Revisit of D1254. Don't require lowercase, just standardize the logic. The current implementation has nonuniform logic -- PeopleEditController forbids uppercase. Test Plan: Ran unit tests, see also D1254. Reviewers: btrahan, jungejason, aran Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D1415
2012-01-16 16:30:28 +01:00
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
Add "Title" and "Blurb" to new profile editor Summary: Ref T1703. - Adds "Title". - Adds "Blurb". - Adds `user.fields` config for selecting and reordering. This will get UI in the next patch. Test Plan: {F45689} {F45690} Edited the fields, too. Reviewers: chad Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6153
2013-06-07 19:22:45 +02:00
'PhabricatorUserTitleField' => 'PhabricatorUserCustomField',
Flesh out ApplicationTransactions/CustomField integration Summary: None of this code is reachable yet. See discussion in D6147. Ref T1703. Provide tighter integration between ApplicationTransactions and CustomField. Basically, I'm just trying to get all the shared stuff into the base implementation. Test Plan: Code not reachable. Reviewers: chad, seporaitis Reviewed By: chad CC: aran Maniphest Tasks: T1703 Differential Revision: https://secure.phabricator.com/D6149
2013-06-06 23:53:07 +02:00
'PhabricatorUserTransaction' => 'PhabricatorApplicationTransaction',
Accept and route VCS HTTP requests Summary: Mostly ripped from D7391, with some changes: - Serve repositories at `/diffusion/X/`, with no special `/git/` or `/serve/` URI component. - This requires a little bit of magic, but I got the magic working for Git, Mercurial and SVN, and it seems reasonable. - I think having one URI for everything will make it easier for users to understand. - One downside is that git will clone into `X` by default, but I think that's not a big deal, and we can work around that in the future easily enough. - Accept HTTP requests for Git, SVN and Mercurial repositories. - Auth logic is a little different in order to be more consistent with how other things work. - Instead of AphrontBasicAuthResponse, added "VCSResponse". Mercurial can print strings we send it on the CLI if we're careful, so support that. I did a fair amount of digging and didn't have any luck with git or svn. - Commands we don't know about are assumed to require "Push" capability by default. No actual VCS data going over the wire yet. Test Plan: Ran a bunch of stuff like this: $ hg clone http://local.aphront.com:8080/diffusion/P/ abort: HTTP Error 403: This repository is not available over HTTP. ...and got pretty reasonable-seeming errors in all cases. All this can do is produce errors for now. Reviewers: hach-que, btrahan Reviewed By: hach-que CC: aran Maniphest Tasks: T2230 Differential Revision: https://secure.phabricator.com/D7417
2013-10-26 16:56:17 +02:00
'PhabricatorVCSResponse' => 'AphrontResponse',
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',
Allow tasks to yield to other tasks Summary: For Harbormaster tasks which want to poll or wait, this lets them say "try again a little later" without having to sleep and hold a queue slot. This is basically the same as failing, except that we don't increment the failure counter. Instead, we just set the current lease to the correct length and then exit. The task will be retried after the lease expires. Test Plan: Using both `bin/harbormaster` and `phd debug taskmaster`, ran a lot of waiting tasks through the queue, faking them to either yield or not yield in a controlled manner. The queue responded as expected, yielding tasks appropraitely and retrying them later. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Differential Revision: https://secure.phabricator.com/D8792
2014-04-16 22:02:12 +02:00
'PhabricatorWorkerYieldException' => 'Exception',
Make repository discovery partially testable Summary: Ref T2784. Begins pulling discovery into Engines and covering it with tests. In particular: - Discovery is currently a one-shot process where we find all the new commits and write them to the database in one go. Split it apart so we find and return the new commits first, then write them to the database separately. This makes things simpler and more testable. - This diff only brings SVN into an engine (and only the "find the commits" part), since it's simpler than Git or Mercurial. - Creates a base Engine class and moves common functionality there. - Restores the `--verbose` flag to `repository pull`. Test Plan: Added unit tests. Ran `bin/repository discover`. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5906
2013-05-13 04:08:37 +02:00
'PhabricatorWorkingCopyDiscoveryTestCase' => 'PhabricatorWorkingCopyTestCase',
Make repository pulls testable Summary: Ref T2784. This moves us toward being able to test the background and Conduit pipelines for repositories. In particular: - Separate the logic for pulling repositories (`git pull`, `hg pull`) out of `PhabricatorRepositoryPullLocalDaemon` and put it in `PhabricatorRepositoryPullEngine`. This allows repositories to be pulled directly without invoking the daemons. - Add tests for the engine, including a future-looking base test case. - Add basic `PhutilDirectoryFixture`-based repositories. Next steps: # Do the same for repo discovery. # Then we can start writing tests against specific Conduit methods. Test Plan: Ran unit tests. Ran `bin/repository pull` on SVN, Hg and Git repositories. Ran `bin/phd debug pulllocal`. Reviewers: btrahan Reviewed By: btrahan CC: aran, nh Maniphest Tasks: T2784 Differential Revision: https://secure.phabricator.com/D5904
2013-05-13 04:05:52 +02:00
'PhabricatorWorkingCopyPullTestCase' => 'PhabricatorWorkingCopyTestCase',
'PhabricatorWorkingCopyTestCase' => 'PhabricatorTestCase',
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',
Move build-time resources to "CelerityPhysicalResources" to fix Phame Summary: Ref T4222. This fixes some issues with Phame's resource construction. Phame requires a fully virtual resource source, and since I want to run wordpress templates unmodified some day I don't want to build resource maps for skins. Move all the stuff that depends on resource lists being discoverable at build time to `CelerityPhysicalResources`, and only generate maps for subclasses. The root `CelerityResources` can now construct virtual resources; construct a virtual resource for Phame and use it. Test Plan: Off-domain blogs work correctly now. On-domain blogs with custom skins work correctly now. Reviewers: btrahan, hach-que Reviewed By: hach-que CC: aran Maniphest Tasks: T4222 Differential Revision: https://secure.phabricator.com/D7873
2014-01-01 04:21:56 +01:00
'PhameCelerityResources' => 'CelerityResources',
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',
Use application PHIDs in Phlux Summary: Ref T2715. PVAR -> app phids Test Plan: Used `conduit.query` to load one. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6557
2013-07-24 23:06:50 +02:00
'PhluxPHIDTypeVariable' => 'PhabricatorPHIDType',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
'PhluxTransaction' => 'PhabricatorApplicationTransaction',
'PhluxTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'PhluxVariable' =>
array(
0 => 'PhluxDAO',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
1 => 'PhabricatorFlaggableInterface',
2 => 'PhabricatorPolicyInterface',
Phlux v0 Summary: Yup, it's sitevars. No conduit or caching or fancy stuff yet. Ref T2793. Test Plan: {F36525} {F36526} {F36527} {F36528} {F36529} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2793 Differential Revision: https://secure.phabricator.com/D5397
2013-03-21 02:01:52 +01:00
),
'PhluxVariableEditor' => 'PhabricatorApplicationTransactionEditor',
'PhluxVariableQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhluxViewController' => 'PhluxController',
Make event-triggered actions more aware of application access Summary: Fixes T3675. - Maniphest had a couple of old non-event listeners; move them to events. - Make most of the similar listeners a little more similar. - Add checks for access to the application. Test Plan: - Viewed profile, project, task, revision. - Clicked all the actions. - Blocked access to various applications and verified the actions vanished. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7365
2013-10-22 02:00:50 +02:00
'PholioActionMenuEventListener' => 'PhabricatorEventListener',
Add a defualt view policy for Pholio Summary: Similar to D8110, but for Pholio. Also an IRC user request. Test Plan: Set setting to something unusual, created a new mock. Reviewers: btrahan Reviewed By: btrahan CC: aran Differential Revision: https://secure.phabricator.com/D8111
2014-01-30 20:53:42 +01:00
'PholioCapabilityDefaultView' => 'PhabricatorPolicyCapability',
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',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
2 => 'PhabricatorPolicyInterface',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
),
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioImageHistoryController' => 'PholioController',
'PholioImageQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioImageUploadController' => 'PholioController',
Show 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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
5 => 'PhabricatorFlaggableInterface',
6 => 'PhabricatorApplicationTransactionInterface',
Remove deprecated `PhabricatorIRCBot` class. Summary: This class has been deprecated for a while (see rP574bc3ba31cca2767bafe7844d7f854d90d6be1c). It should be safe to remove now. Test Plan: N/A Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9469
2014-06-11 14:49:52 +02:00
7 => 'PhabricatorProjectInterface',
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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PholioMockListController' => 'PholioController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PholioMockMailReceiver' => 'PhabricatorObjectMailReceiver',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch in Pholio Summary: Ref T2637. Ref T2625. Convert Pholio to use ApplicationSearch. Test Plan: Viewed mocks, changed filters. Verified edit page works and no longer has a weird side nav on it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T2625, T2637 Differential Revision: https://secure.phabricator.com/D6530
2013-07-22 21:21:15 +02:00
'PholioMockSearchEngine' => 'PhabricatorApplicationSearchEngine',
Add very basic scaffolding for Pholio Summary: I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc. Basic hierarchy is: - **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas". - **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed. - **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits. - **PixelComment**: Equivalent of an inline comment. Test Plan: Created a fake object and viewed it. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran, davidreuss Maniphest Tasks: T2097 Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
'PholioMockViewController' => 'PholioController',
Pholio - add concept of replacing images and primitive history view Summary: Now you can actually replace an image! Ref T3572. This ended up needing a wee bit of infrastructure to work... - add replace image transaction to pholio - add replacesImagePHID to PholioImage - tweaks to editor to properly update images with respect to replacement - add edges to track replacement - expose getNodes on graph query infrastructure to query the entire graph of who replaced who - move pholio image to new phid infrastructure Still TODO - the history view should get chopped out a bit from the current view - no more inline comments / generally less functionality plus maybe a tweak or two to make this more sensical. Test Plan: replaced images and played with history controller a little. works okay. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3572 Differential Revision: https://secure.phabricator.com/D6560
2013-07-26 01:59:25 +02:00
'PholioPHIDTypeImage' => 'PhabricatorPHIDType',
Use application PHIDs in Pholio Mocks Summary: Ref T2715. Switch mocks to the new stuff. Test Plan: Used `phid.query` and `phid.lookup` to find mocks. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6517
2013-07-21 21:40:51 +02:00
'PholioPHIDTypeMock' => 'PhabricatorPHIDType',
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',
Pholio - make the form maintain client side edits between file uploads Summary: Fixes T3553. Did it by adding some code that refreshes the File object on keyup events within a given file entry. also fixes an html derp I found trying to fix this. Test Plan: added cool things like 'bbb' to every field and noted they were maintained when I added more files Reviewers: btrahan Reviewed By: btrahan CC: aran, Korvin, chad Maniphest Tasks: T3553 Differential Revision: https://secure.phabricator.com/D6488
2013-07-19 00:04:08 +02:00
'PholioUploadedImageView' => 'AphrontView',
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',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentBrowseController' => 'PhragmentController',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentCapabilityCanCreate' => 'PhabricatorPolicyCapability',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentController' => 'PhabricatorController',
'PhragmentCreateController' => 'PhragmentController',
'PhragmentDAO' => 'PhabricatorLiskDAO',
'PhragmentFragment' =>
array(
0 => 'PhragmentDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhragmentFragmentQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhragmentFragmentVersion' =>
array(
0 => 'PhragmentDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhragmentFragmentVersionQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentHistoryController' => 'PhragmentController',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPHIDTypeFragment' => 'PhabricatorPHIDType',
'PhragmentPHIDTypeFragmentVersion' => 'PhabricatorPHIDType',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentPHIDTypeSnapshot' => 'PhabricatorPHIDType',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentPatchController' => 'PhragmentController',
Phragment v0 Summary: Ref T4205. This is an initial implementation of Phragment. You can create and browse fragments in the system (but you can't yet view a fragment's patches / history). Test Plan: Clicked around and created fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7726
2013-12-07 02:43:49 +01:00
'PhragmentPatchUtil' => 'Phobject',
Implement policies in Phragment Summary: This implements support for enforcing and setting policies in Phragment. Test Plan: Set policies and ensured they were enforced successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7751
2013-12-13 04:42:12 +01:00
'PhragmentPolicyController' => 'PhragmentController',
Implement "Revert to Version" functionality in Phragment Summary: This functionality allows users to revert a fragment to a previous version from the history page. Reverting a version actually creates a new version pointing at the same file as the version being "reverted" to. In this sense it acts pretty much like Git and other distributed VCS where once you have published a commit the only way to undo your changes is to create a new commit that reverts those changes. Test Plan: Reverted a fragment to a version before it was deleted, then reverted it to when it was deleted and saw the new versions have the correct file PHIDs (including null for the deletion). Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7738
2013-12-08 21:57:53 +01:00
'PhragmentRevertController' => 'PhragmentController',
Implement snapshots in Phragment Summary: Ref T4212. This implements snapshots in Phragment, which allows you to take a snapshot of a fragment at a given point in time, and download a ZIP of the snapshot as it was in this state. There's also functionality for deleting and promoting snapshots. You can promote a snapshot to either the latest version or any other snapshot of the fragment. Test Plan: Clicked around, took some snapshots, promoted them to different points and deleted snapshots. Also downloaded ZIPs of the snapshots and saw the right versions coming through for all the files downloaded. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205, T4212 Differential Revision: https://secure.phabricator.com/D7741
2013-12-08 22:24:50 +01:00
'PhragmentSnapshot' =>
array(
0 => 'PhragmentDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhragmentSnapshotChild' =>
array(
0 => 'PhragmentDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhragmentSnapshotChildQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhragmentSnapshotCreateController' => 'PhragmentController',
'PhragmentSnapshotDeleteController' => 'PhragmentController',
'PhragmentSnapshotPromoteController' => 'PhragmentController',
'PhragmentSnapshotQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
'PhragmentSnapshotViewController' => 'PhragmentController',
Implement update and history controllers in Phragment Summary: Depends on D7726. This adds a history controller (for viewing a list of patches associated with a fragment) and an update controller, for creating a new patch of a fragment. Test Plan: Updated and viewed history of fragments. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7727
2013-12-07 02:56:55 +01:00
'PhragmentUpdateController' => 'PhragmentController',
Implement viewing versions and downloading patches in Phragment Summary: This adds support for viewing individual versions on a fragment as well as comparing versions and downloading diff_match_patch-based patches. It does not use the side-by-side diff format as while it works for small changes, it quickly becomes impossible to distingush what changes have been made due to the diff_match_patch format. Test Plan: Clicked on versions and downloaded patches. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7734
2013-12-08 02:14:34 +01:00
'PhragmentVersionController' => 'PhragmentController',
Implement "Download ZIP" controller for Phragment Summary: Depends on D7727. This adds support for downloading a fragment and all it's children as a ZIP file. Fragments that have children automatically become directories in the ZIP file. Test Plan: Downloaded a fragment as a ZIP and was able to extract the contents successfully. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T4205 Differential Revision: https://secure.phabricator.com/D7728
2013-12-07 03:25:22 +01:00
'PhragmentZIPController' => 'PhragmentController',
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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhrequentListController' => 'PhrequentController',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
'PhrequentSearchEngine' => 'PhabricatorApplicationSearchEngine',
Make Phrequent time accounting aware of the stack Summary: Ref T3569. Fixes T3567. When figuring out how much time has been spent on an object, subtract "preemptive" events which interrupted the object. Also, make the UI look vaguely sane: {F72773} Test Plan: Added a bunch of unit tests, mucked around in the UI. Reviewers: btrahan Reviewed By: btrahan CC: hach-que, skyronic, aran Maniphest Tasks: T3567, T3569 Differential Revision: https://secure.phabricator.com/D7349
2013-10-18 21:47:36 +02:00
'PhrequentTimeBlock' => 'Phobject',
'PhrequentTimeBlockTestCase' => 'PhabricatorTestCase',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhrequentUIEventListener' => 'PhabricatorEventListener',
Update Phrequent to use new search infrastructure. Summary: This updates Phrequent to use new the search infrastructure. Now it looks like: {F60141} I've also added the policy infrastructure stubs, but it's probably not even close to being right in terms of enforcing policies (in particular being able to see time tracked against objects the user wouldn't normally be able to see). At some point I'd like to be able to filter on the objects that the time is tracked against, but I don't believe there's a tokenizer / readahead control that allows you to type any kind of object. Test Plan: Clicked around the new interface, created some custom queries and saved them. Reviewers: epriestley CC: Korvin, aran Maniphest Tasks: T3870 Differential Revision: https://secure.phabricator.com/D7163
2013-10-01 22:04:47 +02:00
'PhrequentUserTime' =>
array(
0 => 'PhrequentDAO',
1 => 'PhabricatorPolicyInterface',
),
'PhrequentUserTimeQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
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',
Tie application event listeners to the applications they listen for Summary: Ref T3675. Some of these listeners shouldn't do their thing if the viewer doesn't have access to an application (for example, users without access to Differential should not be able to "Edit Tasks"). Set the stage for that: - Introduce `PhabricatorEventListener`, which has an application. - Populate this for event listeners installed by applications. - Rename the "PeopleMenu" listeners to "ActionMenu" listeners, which better describes their modern behavior. This doesn't actually change any behaviors. Test Plan: Viewed Maniphest, Differntial, People. Reviewers: btrahan, chad Reviewed By: btrahan CC: aran Maniphest Tasks: T3675 Differential Revision: https://secure.phabricator.com/D7364
2013-10-22 02:00:21 +02:00
'PhrictionActionMenuEventListener' => 'PhabricatorEventListener',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
3 => 'PhabricatorFlaggableInterface',
4 => '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',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PhrictionListController' => 'PhrictionController',
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',
Use application PHIDs in Phriction Summary: Ref T2715. Moves Phriction to application PHIDs. Test Plan: Used `phid.query`; browsed Phriction. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6553
2013-07-24 20:32:13 +02:00
'PhrictionPHIDTypeDocument' => 'PhabricatorPHIDType',
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',
Add breadcrumbs and ApplicationSearch to Phriction Summary: Fixes T3631. Also adds ApplicationSearch. Test Plan: Viewed "New", "Edit"; saw breadcrumbs. Viewed "index", saw application search. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T3631 Differential Revision: https://secure.phabricator.com/D6593
2013-07-28 03:26:42 +02:00
'PhrictionSearchEngine' => 'PhabricatorApplicationSearchEngine',
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',
'PonderAnswer' =>
array(
0 => 'PonderDAO',
1 => 'PhabricatorMarkupInterface',
2 => 'PonderVotableInterface',
Use Application PHIDs for ANSW Summary: Ref T2715. Ref T3578. - Use Application PHIDs for Ponder Answers. - Make Ponder answers policy-aware. - Make PonderAnswerQuery policy-aware. Test Plan: Used `phid.query`; browsed Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6582
2013-07-26 22:19:49 +02:00
3 => 'PhabricatorPolicyInterface',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
4 => 'PhabricatorFlaggableInterface',
5 => 'PhabricatorSubscribableInterface',
6 => '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
),
Restore comments on Ponder answers Summary: Ref T3373. This is still pretty messy: - The JS bugs out a bit with multiple primary object PHIDs on a single page. I'll fix this in a followup. - The comment form itself is enormous, I'll restore some show/hide stuff in a followup. Test Plan: Added answer comments in Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6608
2013-07-29 02:40:11 +02:00
'PonderAnswerCommentController' => 'PonderController',
Allow ponder answers to be edited Summary: Ref T3373. Use applicationtransactions to edit ponder answers. Also enable tokens and subscriptions. Test Plan: edited an answer Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6607
2013-07-29 02:23:04 +02:00
'PonderAnswerEditController' => 'PonderController',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderAnswerEditor' => 'PonderEditor',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderAnswerHistoryController' => 'PonderController',
Use Application PHIDs for ANSW Summary: Ref T2715. Ref T3578. - Use Application PHIDs for Ponder Answers. - Make Ponder answers policy-aware. - Make PonderAnswerQuery policy-aware. Test Plan: Used `phid.query`; browsed Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6582
2013-07-26 22:19:49 +02:00
'PonderAnswerQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderAnswerSaveController' => 'PonderController',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderAnswerTransaction' => 'PhabricatorApplicationTransaction',
'PonderAnswerTransactionComment' => 'PhabricatorApplicationTransactionComment',
Make Ponder use ApplicationTransaction rendering for answers Summary: Ref T3373. This breaks some stuff, but future diffs will fix it. Test Plan: Viewed some questions, saw answer text. Reviewers: btrahan Reviewed By: btrahan CC: aran, chad Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6604
2013-07-29 01:17:51 +02:00
'PonderAnswerTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
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',
),
'PonderCommentQuery' => 'PhabricatorQuery',
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',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderEditor' => 'PhabricatorApplicationTransactionEditor',
Use Application PHIDs for ANSW Summary: Ref T2715. Ref T3578. - Use Application PHIDs for Ponder Answers. - Make Ponder answers policy-aware. - Make PonderAnswerQuery policy-aware. Test Plan: Used `phid.query`; browsed Ponder. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715, T3578 Differential Revision: https://secure.phabricator.com/D6582
2013-07-26 22:19:49 +02:00
'PonderPHIDTypeAnswer' => 'PhabricatorPHIDType',
Use Application PHIDs in Ponder Summary: Ref T2715. Switch Ponder to the new IDs. Test Plan: Ran `phid.lookup`; `phid.query`. Grepped for old constant Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6554
2013-07-24 20:32:31 +02:00
'PonderPHIDTypeQuestion' => 'PhabricatorPHIDType',
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',
Add filter by object ability to flag query Summary: See title. Fixes T1809. Test Plan: verified each type that has flaggable interface still can be flagged verified that new custom query filter works Reviewers: epriestley Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1809 Differential Revision: https://secure.phabricator.com/D7392
2013-10-25 21:52:00 +02:00
4 => 'PhabricatorFlaggableInterface',
5 => 'PhabricatorPolicyInterface',
6 => 'PhabricatorTokenReceiverInterface',
Remove deprecated `PhabricatorIRCBot` class. Summary: This class has been deprecated for a while (see rP574bc3ba31cca2767bafe7844d7f854d90d6be1c). It should be safe to remove now. Test Plan: N/A Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley, #blessed_reviewers Subscribers: epriestley, Korvin Differential Revision: https://secure.phabricator.com/D9469
2014-06-11 14:49:52 +02:00
7 => 'PhabricatorProjectInterface',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
),
Restore Ponder question commenting Summary: Ref T3373. Same issues as the other commenting patch; it's huge and the JS is a bit buggy. Backend is fine, though. Test Plan: Made some comments on a question. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6610
2013-07-29 02:58:34 +02:00
'PonderQuestionCommentController' => 'PonderController',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionEditController' => 'PonderController',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderQuestionEditor' => 'PonderEditor',
Move non-comment transactions to a separate history view in Ponder Summary: Ref T3373. Most edits aren't too interesting, put them on a separate history page. Test Plan: Viewed question page; viewed history page for question and answer. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6612
2013-07-29 03:32:55 +02:00
'PonderQuestionHistoryController' => 'PonderController',
Move more rendering into SearchEngines for panels Summary: Ref T4986. Getting closer. Nothing out of the ordinary in this group. Test Plan: For each application: - Viewed the normal search results. - Created a panel version and viewed it. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9024
2014-05-09 21:25:52 +02:00
'PonderQuestionListController' => 'PonderController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'PonderQuestionMailReceiver' => 'PhabricatorObjectMailReceiver',
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',
Restore mail to Ponder Summary: Ref T3578. Use ApplicationTransactions mail. Test Plan: {F52159} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578 Differential Revision: https://secure.phabricator.com/D6620
2013-07-29 17:38:25 +02:00
'PonderQuestionReplyHandler' => 'PhabricatorMailReplyHandler',
Use ApplicationSearch in Ponder Summary: Ref T2625. Also modernize some other things: - Fix double-"subscribers". - Use byline and more standard date. - Modernize some of the use of crumbs and navigation. - Delete some dead / uncalled code. Test Plan: {F50669} Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3578, T2625 Differential Revision: https://secure.phabricator.com/D6486
2013-07-18 21:40:51 +02:00
'PonderQuestionSearchEngine' => 'PhabricatorApplicationSearchEngine',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderQuestionStatus' => 'PonderConstants',
'PonderQuestionStatusController' => 'PonderController',
Add question and answer transactions to Ponder Summary: Ref T3373. Test Plan: Ran this script, saw valid inserts: <?php $unguarded = AphrontWriteGuard::beginScopedUnguardedWrites(); id(new PonderQuestionTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransaction()) ->setAuthorPHID('herp') ->setObjectPHID('derp') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setTransactionType('beep') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderQuestionTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); id(new PonderAnswerTransactionComment()) ->setCommentVersion(1) ->setAuthorPHID('bloop') ->setViewPolicy('blarp') ->setEditPolicy('goop') ->setContent('blip') ->setContentSource(PhabricatorContentSource::newForSource('derp', array())) ->save(); unset($unguarded); echo "OK!\n"; Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6584
2013-07-26 22:52:57 +02:00
'PonderQuestionTransaction' => 'PhabricatorApplicationTransaction',
'PonderQuestionTransactionComment' => 'PhabricatorApplicationTransactionComment',
Make PonderQuestionEditor use ApplicationTransactions Summary: Ref T3373. Make PonderQuestions editable and use transactions. This temporarily disables some stuff: - email; - feed; - comments; - voting. I'll restore those in followups and wait to land this until they're at least mostly back online. The transactions themselves also need more string/color/icon work. Test Plan: Created and edited questions. Viewed transactions. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3373 Differential Revision: https://secure.phabricator.com/D6601
2013-07-29 00:02:18 +02:00
'PonderQuestionTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Adding Ponder-related files. Summary: Ponder is similar in spirit to the Wiki tool, but uses a Q&A format and up/downvotes to signal user sentiment. Popular questions are moved to the top of the feed on a 5-minute cycle based on age (younger is better) and vote count (higher is better). Pre-apologies for noob diff. Test Plan: - `./bin/phd list` Should include `PonderHeatDaemon`; phd launch it if necessary. - Navigate to /ponder/ ; observe sanity when adding questions, voting on them, and adding answers. - Confirm that questions and answers are linkable using Q5 / Q5#A5 formatted object links. - Confirm that searching for Ponder Questions works using built-in search. Feedback on code / schema / whatever organization very welcome. Reviewers: nh, vrana, epriestley Reviewed By: epriestley CC: gmarcotte, aran, Korvin, starruler Differential Revision: https://secure.phabricator.com/D3136
2012-08-10 19:44:04 +02:00
'PonderQuestionViewController' => 'PonderController',
Missing change from D5120 which I incorrectly discarded in a merge. Auditors: vrana
2013-02-27 16:18:30 +01:00
'PonderRemarkupRule' => 'PhabricatorRemarkupRuleObject',
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',
Ponder - make feed stories and emails a bit better Summary: Also some random cleanup now and again. Note reply handler stuff is kind of bojangles bad right now. It didn't work before though either so hey. Test Plan: asked questions, answered questions, edited answers... the feed pleased my eye Reviewers: epriestley Reviewed By: epriestley CC: Korvin, aran Maniphest Tasks: T3653 Differential Revision: https://secure.phabricator.com/D7027
2013-09-19 00:15:25 +02:00
'PonderTransactionFeedStory' => 'PhabricatorApplicationTransactionFeedStory',
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
'PonderVotableView' => 'AphrontView',
Allowing Closing of questions Summary: Fixes T3579 As a basic overview, this enables the author of a question to open/close a question. Other bits; - Add "Open" filter to the builtin queries - Add "Status" to search form - Refactor ponder constants - Add coloured bars for different question statuses Test Plan: - Open/Close questions - Search for some bits - Use filters Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin Maniphest Tasks: T3579 Differential Revision: https://secure.phabricator.com/D6590 Conflicts: src/infrastructure/storage/patch/PhabricatorBuiltinPatchList.php
2013-07-28 03:37:17 +02:00
'PonderVote' => 'PonderConstants',
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',
Add a 'create' policy to Project Summary: UX on this could probably be better 'disabled' crumbs don't appear to have any visible difference, and the policy error has to load the /create page rather than being a modal - not sure on the way to fix these. Test Plan: Tried to create a project with and without access, saw suitable error. Reviewers: epriestley, #blessed_reviewers CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7279
2013-10-10 13:29:07 +02:00
'ProjectCapabilityCreateProjects' => 'PhabricatorPolicyCapability',
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
'ReleephAuthorFieldSpecification' => 'ReleephFieldSpecification',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephBranch' =>
array(
0 => 'ReleephDAO',
1 => 'PhabricatorPolicyInterface',
),
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchAccessController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchCommitFieldSpecification' => 'ReleephFieldSpecification',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchController' => 'ReleephController',
'ReleephBranchCreateController' => 'ReleephProductController',
'ReleephBranchEditController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchEditor' => 'PhabricatorEditor',
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
'ReleephBranchHistoryController' => 'ReleephBranchController',
Use ApplicationSearch in Releeph project list Summary: Ref T3092. Convert Releeph project list to ApplicationSearch. Test Plan: {F50333} Reviewers: btrahan, edward Reviewed By: edward CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6474
2013-07-21 17:44:53 +02:00
'ReleephBranchNamePreviewController' => 'ReleephController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephBranchPreviewView' => 'AphrontFormControl',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephBranchQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Use ApplicationSearch for Releeph branch lists Summary: Releeph branch lists in project views have a bunch of custom UI right now; give them more standard UI and ApplicationSearch. This drops a small piece of functionality: we now show only a total open request count instead of a detailed enumeration of each request status. I assume this is reasonable (that is, the important piece is "is there something to do on this branch?"), but we can muck with it if the more detailed status is important. Test Plan: {F54344} Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3656 Differential Revision: https://secure.phabricator.com/D6764
2013-08-17 03:55:35 +02:00
'ReleephBranchSearchEngine' => 'PhabricatorApplicationSearchEngine',
Remove ReleephBranchBoxView Summary: Ref T3092. This was obsoleted recently and has no more call/use sites. Test Plan: `grep` Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3092 Differential Revision: https://secure.phabricator.com/D6779
2013-08-20 18:31:27 +02:00
'ReleephBranchTransaction' => 'PhabricatorApplicationTransaction',
Provide a history controller for Releeph branches Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet. Test Plan: Clicked "View History", got a blank but non-broken page. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3663 Differential Revision: https://secure.phabricator.com/D6787
2013-08-20 19:11:52 +02:00
'ReleephBranchTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
'ReleephBranchViewController' =>
array(
Move Releeph branch controllers toward a modern/stable state Summary: Ref T3644. Ref T3657. Ref T3549. Basically: - Move these controllers to modern query/policy infrastructure. - Move them to consistent, ID-based URIs. - Rename "Project" to "Product"; "Pick Request" to "Pull Request". - Clean up a few UI things here and there. Test Plan: - Created and edited branches. - Opened and closed branches. - Viewed branch history. - Searched within a branch. - Browsed to branches from products. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3644, T3549, T3657 Differential Revision: https://secure.phabricator.com/D8646
2014-04-13 01:53:51 +02:00
0 => 'ReleephBranchController',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephCommitFinderException' => 'Exception',
'ReleephCommitMessageFieldSpecification' => 'ReleephFieldSpecification',
'ReleephController' => 'PhabricatorController',
'ReleephDAO' => 'PhabricatorLiskDAO',
'ReleephDefaultFieldSelector' => 'ReleephFieldSelector',
Add dependencies to releeph Summary: Add the 'Depends On' field to releeph requests. This will help the release engineers to be aware of the dependencies and make sure pick them altogether. Test Plan: Check sandbox. This field shows up when a revision has some dependencies. Reviewers: JoelB, lifeihuang, epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Differential Revision: https://secure.phabricator.com/D7946
2014-01-14 03:18:26 +01:00
'ReleephDependsOnFieldSpecification' => 'ReleephFieldSpecification',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephDiffChurnFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffMessageFieldSpecification' => 'ReleephFieldSpecification',
'ReleephDiffSizeFieldSpecification' => 'ReleephFieldSpecification',
'ReleephFieldParseException' => 'Exception',
Partially move Releeph custom fields to PhabricatorCustomField Summary: Fixes T3661. Ref T3718. This makes Releeph custom fields extend PhabricatorCustomField so we can start moving over other pieces of infrastructure (rendering, storage, etc) to run through the same pathways. It's roughly the minimum amount of work required to be able to move forward. NOTE: This removes per-project custom field selectors. Fields are now configured for an entire install. My understanding is that Facebook does not use this feature, and modern field infrastructure has moved away from selectors. Test Plan: Viewed and edited projects, branches, and requests in Releeph. Grepped for removed config. Grepped for `field_selector`. Reviewers: btrahan Reviewed By: btrahan CC: LegNeato, aran Maniphest Tasks: T3661, T3718 Differential Revision: https://secure.phabricator.com/D6750
2013-08-14 17:58:54 +02:00
'ReleephFieldSpecification' =>
array(
0 => 'PhabricatorCustomField',
1 => '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
'ReleephIntentFieldSpecification' => 'ReleephFieldSpecification',
'ReleephLevelFieldSpecification' => 'ReleephFieldSpecification',
'ReleephOriginalCommitFieldSpecification' => 'ReleephFieldSpecification',
Use application PHIDs in Releeph, plus more Summary: Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small: - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write. - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results. - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project. - Implement `ReleephBranchQuery`. - Move the branch PHID type to application PHID infrastructure. Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T603, T2715, T3551 Differential Revision: https://secure.phabricator.com/D6512
2013-07-21 18:27:00 +02:00
'ReleephPHIDTypeBranch' => 'PhabricatorPHIDType',
Rename Releeph "Project" PHID type to "Product" Summary: Ref T3549. Test Plan: `grep`, loaded some pages Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8811
2014-04-19 02:52:45 +02:00
'ReleephPHIDTypeProduct' => 'PhabricatorPHIDType',
Use application handle infrastructure for Releeph Requests and Releeph Projects Summary: Ref T2715. Test Plan: Used `phid.query` to query handles. Browsed Releeph. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T2715 Differential Revision: https://secure.phabricator.com/D6510
2013-07-21 17:41:38 +02:00
'ReleephPHIDTypeRequest' => 'PhabricatorPHIDType',
Modernize Releeph "Product Activate" controller Summary: Ref T3549. A few things here: - Releeph has an object called a "Project". We'd like to call this a "Product" instead. See T3549. Rename easy instances that don't break URIs. - Releeph has a "ProjectController" which tries to be smart about loading objects. However, it's big and messy and doesn't have the finesse to do policies or `needX(...)` correctly. It also generates URIs which collide with one another. Introduce "ProductController" to start to move away from it. - Some small modernizations to this controller to take advantage of newer infrastructure (like easier dialog rendering). Test Plan: Deactivated and reactivated products. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8632
2014-03-29 17:14:44 +01:00
'ReleephProductActionController' => 'ReleephProductController',
'ReleephProductController' => 'ReleephController',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephProductCreateController' => 'ReleephProductController',
Rename project -> product on edit/create UIs Summary: Ref T3092. Ref T3549. Modernize the product creation and edit UIs and make them say "product" instead of "project". Test Plan: - Created products. - Edited products. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3092, T3549 Differential Revision: https://secure.phabricator.com/D8636
2014-03-29 17:16:40 +01:00
'ReleephProductEditController' => 'ReleephProductController',
Use ApplicationTransactions for Releeph product activity Summary: Ref T3549. Ref T3663. - Use transactions for activate/deactivate. - Rename some "project" -> "product". Test Plan: - Activated products. - Deactivated products. {F135480} Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3663, T3549 Differential Revision: https://secure.phabricator.com/D8634
2014-03-29 17:16:02 +01:00
'ReleephProductEditor' => 'PhabricatorApplicationTransactionEditor',
'ReleephProductHistoryController' => 'ReleephProductController',
Move even more rendering into SearchEngine Summary: Ref T4986. I think this is the last of the easy ones, there are about 10 not-quite-so-trivial ones left. Test Plan: - Viewed app results. - Created panels. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T4986 Differential Revision: https://secure.phabricator.com/D9025
2014-05-09 21:28:02 +02:00
'ReleephProductListController' => 'ReleephController',
Rename ReleephProjectQuery to ReleephProductQuery Summary: Ref T3549. Test Plan: grep/lint Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8815
2014-04-20 20:51:02 +02:00
'ReleephProductQuery' => 'PhabricatorCursorPagedPolicyAwareQuery',
Rename more project -> product in Releeph Summary: Ref T3549. - Renames most "project" in view/list controllers. - Moves away from "ProjectController". - Modernizes some modern UI. Test Plan: - Viewed product lists. - Viewed product detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8635
2014-03-29 17:16:24 +01:00
'ReleephProductSearchEngine' => 'PhabricatorApplicationSearchEngine',
Rename Releeph "Project" transactions to "Product" Summary: Ref T3549. This table isn't written to yet; rename it and the DAOs and modernize the history controller. Test Plan: Viewed history page for a product. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8633
2014-03-29 17:15:09 +01:00
'ReleephProductTransaction' => 'PhabricatorApplicationTransaction',
'ReleephProductTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
Rename more project -> product in Releeph Summary: Ref T3549. - Renames most "project" in view/list controllers. - Moves away from "ProjectController". - Modernizes some modern UI. Test Plan: - Viewed product lists. - Viewed product detail pages. Reviewers: btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3549 Differential Revision: https://secure.phabricator.com/D8635
2014-03-29 17:16:24 +01:00
'ReleephProductViewController' =>
array(
0 => 'ReleephProductController',
1 => 'PhabricatorApplicationSearchResultsControllerInterface',
),
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
'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',
Make ReleephRequest implement PhabricatorCustomFieldInterface Summary: Ref T3718. Doesn't do anything yet. Test Plan: Viewed and edited a request. Reviewers: btrahan Reviewed By: btrahan CC: aran Maniphest Tasks: T3718 Differential Revision: https://secure.phabricator.com/D6753
2013-08-14 19:04:18 +02:00
2 => 'PhabricatorCustomFieldInterface',
Add get Releeph Requests conduit method Summary: Added "getrequests" conduit method Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs. Reviewers: edward, epriestley Reviewed By: edward CC: aran, epriestley, Korvin Maniphest Tasks: T3057 Differential Revision: https://secure.phabricator.com/D5788
2013-04-26 18:07:38 +02:00
),
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestActionController' => 'ReleephRequestController',
'ReleephRequestCommentController' => 'ReleephRequestController',
'ReleephRequestController' => 'ReleephController',
'ReleephRequestDifferentialCreateController' => 'ReleephController',
'ReleephRequestEditController' => 'ReleephBranchController',
Move some received mail responsibility to applications Summary: Ref T1205. Continuation of D5915. Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular: - New mail receivers in applications must edit it. - Mail receivers don't drop out when applications are uninstalled. Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail). Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely. For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled. I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications. Test Plan: Unit tests, used receive test to route mail to various objects. Reviewers: btrahan Reviewed By: btrahan CC: Afaque_Hussain, edward, aran Maniphest Tasks: T1205 Differential Revision: https://secure.phabricator.com/D5922
2013-05-14 19:57:41 +02:00
'ReleephRequestMailReceiver' => 'PhabricatorObjectMailReceiver',
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',
Use ApplicationSearch in ReleephBranchView Summary: Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field). ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later. Test Plan: {F54304} Reviewers: btrahan Reviewed By: btrahan CC: chad, aran Maniphest Tasks: T3721 Differential Revision: https://secure.phabricator.com/D6758
2013-08-15 00:38:52 +02:00
'ReleephRequestSearchEngine' => 'PhabricatorApplicationSearchEngine',
ReleephRequest xactions Summary: Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well. This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.) Test Plan: * Make requests, then pick them. * Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening. * Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.) * Load all of FB's Releeph data into my DB and run the `storage upgrade` script. * Request a commit via the "action" in a Differential revision. Reviewers: epriestley Reviewed By: epriestley CC: epriestley, aran, Korvin, wez Maniphest Tasks: T3092, T2720 Differential Revision: https://secure.phabricator.com/D5868
2013-04-08 17:34:21 +02:00
'ReleephRequestTransaction' => 'PhabricatorApplicationTransaction',
'ReleephRequestTransactionComment' => 'PhabricatorApplicationTransactionComment',
'ReleephRequestTransactionQuery' => 'PhabricatorApplicationTransactionQuery',
'ReleephRequestTransactionalEditor' => 'PhabricatorApplicationTransactionEditor',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestTypeaheadControl' => 'AphrontFormControl',
'ReleephRequestTypeaheadController' => 'PhabricatorTypeaheadDatasourceController',
Use standard UI elements to render pull requests in Releeph Summary: Ref T3718. Ref T3644. Ref T3092. Switches from the Releeph UI elements to standard ones. I'll attach some screenshots. Also fixes CSRF against the request action endpoint. Test Plan: - Viewed request details. - Took actions on a request from detail page. - Viewed request list. - Took actions on a request from list page. - Used keyboard shortcuts to navigate list. - Used keyboard shortcuts to take actions. - Simulated errors. - Viewed on devices. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: grp, FacebookPOC, mattlqx, tala, beng, LegNeato, epriestley Maniphest Tasks: T3718, T3092, T3644 Differential Revision: https://secure.phabricator.com/D8771
2014-04-18 15:44:45 +02:00
'ReleephRequestView' => 'AphrontView',
Remove ReleephProjectController Summary: Ref T3657. General changes here: - Removes `ReleephProjectController`, which is the source of T3657. - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs. - Makes requests implement policies correctly. Test Plan: Created, edited, browsed requests. Reviewers: chad, btrahan Reviewed By: btrahan Subscribers: epriestley Maniphest Tasks: T3657 Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 21:06:56 +02:00
'ReleephRequestViewController' => 'ReleephBranchController',
Releeph (Phabricator part) Summary: A copy of the Releeph release tool. Test Plan: Generally, click everything at least once. Reviewers: epriestley Reviewed By: epriestley CC: aran, Korvin, AnhNhan Maniphest Tasks: T2094 Differential Revision: https://secure.phabricator.com/D4932
2013-03-15 12:28:43 +01:00
'ReleephRequestorFieldSpecification' => 'ReleephFieldSpecification',
'ReleephRevisionFieldSpecification' => 'ReleephFieldSpecification',
'ReleephSeverityFieldSpecification' => 'ReleephLevelFieldSpecification',
'ReleephSummaryFieldSpecification' => 'ReleephFieldSpecification',
Implemented support for build logs Summary: Depends on D7519. This implements support for build logs in Harbormaster. This includes support for appending to a log from the "Run Remote Command" build step. It also adds the ability to cancel builds. Currently the build view page doesn't update the logs live; I'm sure this can be achieved with Javelin, but I don't have enough experience with Javelin to actually make it poll from updates to content in the background. {F79151} {F79153} {F79150} {F79152} Test Plan: Tested this by setting up SSH on a Windows machine and using a Remote Command configured with: ``` C:\Windows\system32\cmd.exe /C cd C:\Build && mkdir Build_${timestamp} && cd Build_${timestamp} && git clone --recursive https://github.com/hach-que/Tychaia.git && cd Tychaia && Protobuild.exe && C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe Tychaia.Windows.sln ``` and observed the output of the build stream from the Windows machine into Phabricator. Reviewers: epriestley, #blessed_reviewers Reviewed By: epriestley CC: Korvin, epriestley, aran Maniphest Tasks: T1049 Differential Revision: https://secure.phabricator.com/D7521
2013-11-09 03:09:03 +01:00
'ShellLogView' => 'AphrontView',
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