2011-01-16 22:51:39 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* This file is automatically generated. Use 'phutil_mapper.php' to rebuild it.
|
|
|
|
* @generated
|
|
|
|
*/
|
|
|
|
|
|
|
|
phutil_register_library_map(array(
|
|
|
|
'class' =>
|
|
|
|
array(
|
2011-05-09 10:10:40 +02:00
|
|
|
'Aphront304Response' => 'aphront/response/304',
|
2011-01-30 21:08:40 +01:00
|
|
|
'Aphront400Response' => 'aphront/response/400',
|
2012-01-15 10:07:56 +01:00
|
|
|
'Aphront403Response' => 'aphront/response/403',
|
2011-01-16 22:51:39 +01:00
|
|
|
'Aphront404Response' => 'aphront/response/404',
|
2011-01-25 20:57:47 +01:00
|
|
|
'AphrontAjaxResponse' => 'aphront/response/ajax',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontApplicationConfiguration' => 'aphront/applicationconfiguration',
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
'AphrontAttachedFileView' => 'view/control/attachedfile',
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
'AphrontCSRFException' => 'aphront/exception/csrf',
|
Build a basic calendar view
Summary:
This is a very small step toward building a Status and possibly an Oncall tool.
Build a calendar view which renders months.
Much of my hesitance to bang these tools out is that dealing with
dates/calendaring is basically horrible, so I'm trying to ease into it.
This calendar is locale-aware and all that jazz.
Test Plan:
- See:
https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/
- Verified that months have the right number of days, today is the right day
of the week, months begin on the day after previous months end on, etc.
Reviewed By: aran
Reviewers: jungejason, tuomaspelkonen, aran
Commenters: cwbeck, jungejason
CC: blair, aran, epriestley, cwbeck, jungejason
Differential Revision: 791
2011-08-08 03:26:31 +02:00
|
|
|
'AphrontCalendarMonthView' => 'applications/calendar/view/month',
|
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' => 'view/layout/contextbar',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontController' => 'aphront/controller',
|
2011-03-13 01:17:34 +01:00
|
|
|
'AphrontCrumbsView' => 'view/layout/crumbs',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontDatabaseConnection' => 'storage/connection/base',
|
2012-01-31 21:07:34 +01:00
|
|
|
'AphrontDatabaseTransactionState' => 'storage/transaction',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontDefaultApplicationConfiguration' => 'aphront/default/configuration',
|
|
|
|
'AphrontDialogResponse' => 'aphront/response/dialog',
|
|
|
|
'AphrontDialogView' => 'view/dialog',
|
|
|
|
'AphrontErrorView' => 'view/form/error',
|
2011-01-26 22:21:12 +01:00
|
|
|
'AphrontException' => 'aphront/exception/base',
|
2011-05-23 02:06:42 +02:00
|
|
|
'AphrontFilePreviewView' => 'view/layout/filepreview',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFileResponse' => 'aphront/response/file',
|
2011-01-26 02:40:21 +01:00
|
|
|
'AphrontFormCheckboxControl' => 'view/form/control/checkbox',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormControl' => 'view/form/control/base',
|
2012-04-04 21:14:10 +02:00
|
|
|
'AphrontFormDateControl' => 'view/form/control/date',
|
2011-02-05 02:53:14 +01:00
|
|
|
'AphrontFormDividerControl' => 'view/form/control/divider',
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
'AphrontFormDragAndDropUploadControl' => 'view/form/control/draganddropupload',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormFileControl' => 'view/form/control/file',
|
2012-03-16 01:10:19 +01:00
|
|
|
'AphrontFormInsetView' => 'view/form/inset',
|
2011-06-10 00:28:29 +02:00
|
|
|
'AphrontFormLayoutView' => 'view/form/layout',
|
2011-01-24 20:36:53 +01:00
|
|
|
'AphrontFormMarkupControl' => 'view/form/control/markup',
|
2011-01-31 20:55:26 +01:00
|
|
|
'AphrontFormPasswordControl' => 'view/form/control/password',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'AphrontFormPolicyControl' => 'view/form/control/policy',
|
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' => 'view/form/control/radio',
|
2011-01-31 20:55:26 +01:00
|
|
|
'AphrontFormRecaptchaControl' => 'view/form/control/recaptcha',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSelectControl' => 'view/form/control/select',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormStaticControl' => 'view/form/control/static',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSubmitControl' => 'view/form/control/submit',
|
|
|
|
'AphrontFormTextAreaControl' => 'view/form/control/textarea',
|
|
|
|
'AphrontFormTextControl' => 'view/form/control/text',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontFormToggleButtonsControl' => 'view/form/control/togglebuttons',
|
2011-01-25 22:48:05 +01:00
|
|
|
'AphrontFormTokenizerControl' => 'view/form/control/tokenizer',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormView' => 'view/form/base',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontHTTPSink' => 'aphront/sink/base',
|
|
|
|
'AphrontHTTPSinkTestCase' => 'aphront/sink/base/__tests__',
|
2011-02-20 21:50:28 +01:00
|
|
|
'AphrontHeadsupActionListView' => 'view/layout/headsup/actionlist',
|
|
|
|
'AphrontHeadsupActionView' => 'view/layout/headsup/action',
|
2012-03-30 23:12:10 +02:00
|
|
|
'AphrontHeadsupView' => 'view/layout/headsup/panel',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'AphrontIDPagerView' => 'view/control/idpager',
|
2011-04-30 19:11:41 +02:00
|
|
|
'AphrontIsolatedDatabaseConnection' => 'storage/connection/isolated',
|
|
|
|
'AphrontIsolatedDatabaseConnectionTestCase' => 'storage/connection/isolated/__tests__',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontIsolatedHTTPSink' => 'aphront/sink/test',
|
2012-02-14 23:51:51 +01:00
|
|
|
'AphrontJSONResponse' => 'aphront/response/json',
|
2011-09-07 23:01:13 +02:00
|
|
|
'AphrontJavelinView' => 'view/javelin-view',
|
2011-06-08 20:53:10 +02:00
|
|
|
'AphrontKeyboardShortcutsAvailableView' => 'view/widget/keyboardshortcuts',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontListFilterView' => 'view/layout/listfilter',
|
2012-02-15 01:23:53 +01:00
|
|
|
'AphrontMiniPanelView' => 'view/layout/minipanel',
|
Prepare for MySQLi support
Summary: This separates common MySQL stuff (identifiers and comments escaping, error codes, connection retries) from PHP extension specific stuff (connect, query, fetch, errors, escape string).
Test Plan:
/
Use `AphrontMySQLiDatabaseConnection` in `PhabricatorLiskDAO`, load homepage, edit task, save task.
Reviewers: epriestley
Reviewed By: epriestley
CC: nh, aran
Differential Revision: https://secure.phabricator.com/D2113
2012-04-06 02:45:11 +02:00
|
|
|
'AphrontMySQLDatabaseConnection' => 'storage/connection/mysql/mysql',
|
|
|
|
'AphrontMySQLDatabaseConnectionBase' => 'storage/connection/mysql/base',
|
2012-02-07 23:58:37 +01:00
|
|
|
'AphrontMySQLDatabaseConnectionTestCase' => 'storage/connection/mysql/__tests__',
|
Prepare for MySQLi support
Summary: This separates common MySQL stuff (identifiers and comments escaping, error codes, connection retries) from PHP extension specific stuff (connect, query, fetch, errors, escape string).
Test Plan:
/
Use `AphrontMySQLiDatabaseConnection` in `PhabricatorLiskDAO`, load homepage, edit task, save task.
Reviewers: epriestley
Reviewed By: epriestley
CC: nh, aran
Differential Revision: https://secure.phabricator.com/D2113
2012-04-06 02:45:11 +02:00
|
|
|
'AphrontMySQLiDatabaseConnection' => 'storage/connection/mysql/mysqli',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontNullView' => 'view/null',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontPHPHTTPSink' => 'aphront/sink/php',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPageView' => 'view/page/base',
|
2011-04-01 02:06:33 +02:00
|
|
|
'AphrontPagerView' => 'view/control/pager',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPanelView' => 'view/layout/panel',
|
2012-01-15 20:06:13 +01:00
|
|
|
'AphrontPlainTextResponse' => 'aphront/response/plaintext',
|
2012-03-13 05:39:05 +01:00
|
|
|
'AphrontProxyResponse' => 'aphront/response/proxy',
|
2011-04-30 09:18:13 +02:00
|
|
|
'AphrontQueryAccessDeniedException' => 'storage/exception/accessdenied',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontQueryConnectionException' => 'storage/exception/connection',
|
|
|
|
'AphrontQueryConnectionLostException' => 'storage/exception/connectionlost',
|
|
|
|
'AphrontQueryCountException' => 'storage/exception/count',
|
2011-01-31 06:28:45 +01:00
|
|
|
'AphrontQueryDuplicateKeyException' => 'storage/exception/duplicatekey',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontQueryException' => 'storage/exception/base',
|
|
|
|
'AphrontQueryObjectMissingException' => 'storage/exception/objectmissing',
|
|
|
|
'AphrontQueryParameterException' => 'storage/exception/parameter',
|
|
|
|
'AphrontQueryRecoverableException' => 'storage/exception/recoverable',
|
2012-03-05 22:17:21 +01:00
|
|
|
'AphrontQuerySchemaException' => 'storage/exception/schema',
|
2011-01-26 22:21:12 +01:00
|
|
|
'AphrontRedirectException' => 'aphront/exception/redirect',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontRedirectResponse' => 'aphront/response/redirect',
|
2011-05-16 20:43:39 +02:00
|
|
|
'AphrontReloadResponse' => 'aphront/response/reload',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontRequest' => 'aphront/request',
|
2011-01-30 18:15:01 +01:00
|
|
|
'AphrontRequestFailureView' => 'view/page/failure',
|
2012-01-04 06:57:45 +01:00
|
|
|
'AphrontRequestTestCase' => 'aphront/request/__tests__',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontResponse' => 'aphront/response/base',
|
Create AphrontWriteGuard, a backup mechanism for CSRF validation
Summary:
Provide a catchall mechanism to find unprotected writes.
- Depends on D758.
- Similar to WriteOnHTTPGet stuff from Facebook's stack.
- Since we have a small number of storage mechanisms and highly structured
read/write pathways, we can explicitly answer the question "is this page
performing a write?".
- Never allow writes without CSRF checks.
- This will probably break some things. That's fine: they're CSRF
vulnerabilities or weird edge cases that we can fix. But don't push to Facebook
for a few days unless you're prepared to deal with this.
- **>>> MEGADERP: All Conduit write APIs are currently vulnerable to CSRF!
<<<**
Test Plan:
- Ran some scripts that perform writes (scripts/search indexers), no issues.
- Performed normal CSRF submits.
- Added writes to an un-CSRF'd page, got an exception.
- Executed conduit methods.
- Did login/logout (this works because the logged-out user validates the
logged-out csrf "token").
- Did OAuth login.
- Did OAuth registration.
Reviewers: pedram, andrewjcg, erling, jungejason, tuomaspelkonen, aran,
codeblock
Commenters: pedram
CC: aran, epriestley, pedram
Differential Revision: 777
2011-08-03 20:49:27 +02:00
|
|
|
'AphrontScopedUnguardedWriteCapability' => 'aphront/writeguard/scopeguard',
|
2011-12-17 02:08:18 +01:00
|
|
|
'AphrontSideNavFilterView' => 'view/layout/sidenavfilter',
|
2011-01-24 18:00:29 +01:00
|
|
|
'AphrontSideNavView' => 'view/layout/sidenav',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontTableView' => 'view/control/table',
|
2011-03-23 04:41:02 +01:00
|
|
|
'AphrontTokenizerTemplateView' => 'view/control/tokenizer',
|
2011-04-04 04:20:47 +02:00
|
|
|
'AphrontTypeaheadTemplateView' => 'view/control/typeahead',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontURIMapper' => 'aphront/mapper',
|
2012-04-24 03:36:25 +02:00
|
|
|
'AphrontUsageException' => 'aphront/exception/usage',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontView' => 'view/base',
|
|
|
|
'AphrontWebpageResponse' => 'aphront/response/webpage',
|
Create AphrontWriteGuard, a backup mechanism for CSRF validation
Summary:
Provide a catchall mechanism to find unprotected writes.
- Depends on D758.
- Similar to WriteOnHTTPGet stuff from Facebook's stack.
- Since we have a small number of storage mechanisms and highly structured
read/write pathways, we can explicitly answer the question "is this page
performing a write?".
- Never allow writes without CSRF checks.
- This will probably break some things. That's fine: they're CSRF
vulnerabilities or weird edge cases that we can fix. But don't push to Facebook
for a few days unless you're prepared to deal with this.
- **>>> MEGADERP: All Conduit write APIs are currently vulnerable to CSRF!
<<<**
Test Plan:
- Ran some scripts that perform writes (scripts/search indexers), no issues.
- Performed normal CSRF submits.
- Added writes to an un-CSRF'd page, got an exception.
- Executed conduit methods.
- Did login/logout (this works because the logged-out user validates the
logged-out csrf "token").
- Did OAuth login.
- Did OAuth registration.
Reviewers: pedram, andrewjcg, erling, jungejason, tuomaspelkonen, aran,
codeblock
Commenters: pedram
CC: aran, epriestley, pedram
Differential Revision: 777
2011-08-03 20:49:27 +02:00
|
|
|
'AphrontWriteGuard' => 'aphront/writeguard',
|
2011-01-31 20:55:26 +01:00
|
|
|
'CelerityAPI' => 'infrastructure/celerity/api',
|
|
|
|
'CelerityResourceController' => 'infrastructure/celerity/controller',
|
2011-11-22 20:36:57 +01:00
|
|
|
'CelerityResourceGraph' => 'infrastructure/celerity/graph',
|
2011-01-31 20:55:26 +01:00
|
|
|
'CelerityResourceMap' => 'infrastructure/celerity/map',
|
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
|
|
|
'CelerityResourceTransformer' => 'infrastructure/celerity/transformer',
|
|
|
|
'CelerityResourceTransformerTestCase' => 'infrastructure/celerity/transformer/__tests__',
|
2011-01-31 20:55:26 +01:00
|
|
|
'CelerityStaticResourceResponse' => 'infrastructure/celerity/response',
|
2011-01-24 18:00:29 +01:00
|
|
|
'ConduitAPIMethod' => 'applications/conduit/method/base',
|
|
|
|
'ConduitAPIRequest' => 'applications/conduit/protocol/request',
|
2012-01-11 01:48:59 +01:00
|
|
|
'ConduitAPIResponse' => 'applications/conduit/protocol/response',
|
2011-09-16 20:42:45 +02:00
|
|
|
'ConduitAPI_arcanist_Method' => 'applications/conduit/method/arcanist/base',
|
|
|
|
'ConduitAPI_arcanist_projectinfo_Method' => 'applications/conduit/method/arcanist/projectinfo',
|
2012-03-07 00:12:27 +01:00
|
|
|
'ConduitAPI_audit_Method' => 'applications/conduit/method/audit/base',
|
|
|
|
'ConduitAPI_audit_query_Method' => 'applications/conduit/method/audit/query',
|
2012-02-17 19:21:38 +01:00
|
|
|
'ConduitAPI_chatlog_Method' => 'applications/conduit/method/chatlog/base',
|
|
|
|
'ConduitAPI_chatlog_query_Method' => 'applications/conduit/method/chatlog/query',
|
|
|
|
'ConduitAPI_chatlog_record_Method' => 'applications/conduit/method/chatlog/record',
|
2011-01-24 20:30:10 +01:00
|
|
|
'ConduitAPI_conduit_connect_Method' => 'applications/conduit/method/conduit/connect',
|
2011-06-14 21:17:14 +02:00
|
|
|
'ConduitAPI_conduit_getcertificate_Method' => 'applications/conduit/method/conduit/getcertificate',
|
2011-02-19 07:36:32 +01:00
|
|
|
'ConduitAPI_conduit_ping_Method' => 'applications/conduit/method/conduit/ping',
|
2011-03-15 21:38:14 +01:00
|
|
|
'ConduitAPI_daemon_launched_Method' => 'applications/conduit/method/daemon/launched',
|
|
|
|
'ConduitAPI_daemon_log_Method' => 'applications/conduit/method/daemon/log',
|
2012-04-24 02:40:57 +02:00
|
|
|
'ConduitAPI_differential_close_Method' => 'applications/conduit/method/differential/close',
|
2011-11-18 18:16:40 +01:00
|
|
|
'ConduitAPI_differential_createcomment_Method' => 'applications/conduit/method/differential/createcomment',
|
2011-01-24 20:01:53 +01:00
|
|
|
'ConduitAPI_differential_creatediff_Method' => 'applications/conduit/method/differential/creatediff',
|
2011-02-06 22:49:23 +01:00
|
|
|
'ConduitAPI_differential_createrevision_Method' => 'applications/conduit/method/differential/createrevision',
|
2011-02-06 23:43:06 +01:00
|
|
|
'ConduitAPI_differential_find_Method' => 'applications/conduit/method/differential/find',
|
2011-04-21 00:29:02 +02:00
|
|
|
'ConduitAPI_differential_getalldiffs_Method' => 'applications/conduit/method/differential/getalldiffs',
|
2011-02-09 18:41:26 +01:00
|
|
|
'ConduitAPI_differential_getcommitmessage_Method' => 'applications/conduit/method/differential/getcommitmessage',
|
2011-02-19 07:28:03 +01:00
|
|
|
'ConduitAPI_differential_getcommitpaths_Method' => 'applications/conduit/method/differential/getcommitpaths',
|
2011-02-19 07:15:28 +01:00
|
|
|
'ConduitAPI_differential_getdiff_Method' => 'applications/conduit/method/differential/getdiff',
|
2011-04-21 01:38:16 +02:00
|
|
|
'ConduitAPI_differential_getrevision_Method' => 'applications/conduit/method/differential/getrevision',
|
2011-12-12 20:55:55 +01:00
|
|
|
'ConduitAPI_differential_getrevisioncomments_Method' => 'applications/conduit/method/differential/getrevisioncomments',
|
2011-04-20 01:24:45 +02:00
|
|
|
'ConduitAPI_differential_getrevisionfeedback_Method' => 'applications/conduit/method/differential/getrevisionfeedback',
|
2011-02-09 18:48:26 +01:00
|
|
|
'ConduitAPI_differential_markcommitted_Method' => 'applications/conduit/method/differential/markcommitted',
|
2011-02-06 22:42:00 +01:00
|
|
|
'ConduitAPI_differential_parsecommitmessage_Method' => 'applications/conduit/method/differential/parsecommitmessage',
|
2011-12-02 01:57:06 +01:00
|
|
|
'ConduitAPI_differential_query_Method' => 'applications/conduit/method/differential/query',
|
2011-01-24 21:07:34 +01:00
|
|
|
'ConduitAPI_differential_setdiffproperty_Method' => 'applications/conduit/method/differential/setdiffproperty',
|
2011-02-06 23:00:32 +01:00
|
|
|
'ConduitAPI_differential_updaterevision_Method' => 'applications/conduit/method/differential/updaterevision',
|
2011-04-22 03:47:04 +02:00
|
|
|
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'applications/conduit/method/differential/updatetaskrevisionassoc',
|
2011-06-09 01:16:59 +02:00
|
|
|
'ConduitAPI_differential_updateunitresults_Method' => 'applications/conduit/method/differential/updateunitresults',
|
2011-12-21 18:39:33 +01:00
|
|
|
'ConduitAPI_diffusion_findsymbols_Method' => 'applications/conduit/method/diffusion/findsymbols',
|
2011-04-14 01:39:08 +02:00
|
|
|
'ConduitAPI_diffusion_getcommits_Method' => 'applications/conduit/method/diffusion/getcommits',
|
2011-05-20 00:36:17 +02:00
|
|
|
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'applications/conduit/method/diffusion/getrecentcommitsbypath',
|
2011-07-05 17:35:18 +02:00
|
|
|
'ConduitAPI_feed_publish_Method' => 'applications/conduit/method/feed/publish',
|
2012-02-03 01:44:05 +01:00
|
|
|
'ConduitAPI_feed_query_Method' => 'applications/conduit/method/feed/query',
|
2011-05-21 18:53:50 +02:00
|
|
|
'ConduitAPI_file_download_Method' => 'applications/conduit/method/file/download',
|
2011-07-29 19:00:16 +02:00
|
|
|
'ConduitAPI_file_info_Method' => 'applications/conduit/method/file/info',
|
2011-01-24 18:00:29 +01:00
|
|
|
'ConduitAPI_file_upload_Method' => 'applications/conduit/method/file/upload',
|
2012-03-28 01:22:40 +02:00
|
|
|
'ConduitAPI_flag_Method' => 'applications/conduit/method/flag/base',
|
|
|
|
'ConduitAPI_flag_query_Method' => 'applications/conduit/method/flag/query',
|
2012-03-09 21:40:03 +01:00
|
|
|
'ConduitAPI_macro_Method' => 'applications/conduit/method/macro/base',
|
|
|
|
'ConduitAPI_macro_query_Method' => 'applications/conduit/method/macro/query',
|
2011-08-18 00:19:48 +02:00
|
|
|
'ConduitAPI_maniphest_Method' => 'applications/conduit/method/maniphest/base',
|
|
|
|
'ConduitAPI_maniphest_createtask_Method' => 'applications/conduit/method/maniphest/createtask',
|
2011-08-27 01:52:57 +02:00
|
|
|
'ConduitAPI_maniphest_find_Method' => 'applications/conduit/method/maniphest/find',
|
2012-01-11 04:51:55 +01:00
|
|
|
'ConduitAPI_maniphest_gettasktransactions_Method' => 'applications/conduit/method/maniphest/gettasktransactions',
|
2011-06-27 10:00:28 +02:00
|
|
|
'ConduitAPI_maniphest_info_Method' => 'applications/conduit/method/maniphest/info',
|
2012-01-06 04:02:50 +01:00
|
|
|
'ConduitAPI_maniphest_update_Method' => 'applications/conduit/method/maniphest/update',
|
2011-07-30 03:31:14 +02:00
|
|
|
'ConduitAPI_paste_Method' => 'applications/conduit/method/paste/base',
|
|
|
|
'ConduitAPI_paste_create_Method' => 'applications/conduit/method/paste/create',
|
2011-06-14 07:21:30 +02:00
|
|
|
'ConduitAPI_paste_info_Method' => 'applications/conduit/method/paste/info',
|
2011-04-12 06:51:36 +02:00
|
|
|
'ConduitAPI_path_getowners_Method' => 'applications/conduit/method/path/getowners',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_phid_Method' => 'applications/conduit/method/phid/base',
|
|
|
|
'ConduitAPI_phid_info_Method' => 'applications/conduit/method/phid/info',
|
2012-02-15 03:26:27 +01:00
|
|
|
'ConduitAPI_phid_query_Method' => 'applications/conduit/method/phid/query',
|
2011-08-26 21:50:28 +02:00
|
|
|
'ConduitAPI_phriction_Method' => 'applications/conduit/method/phriction/base',
|
|
|
|
'ConduitAPI_phriction_edit_Method' => 'applications/conduit/method/phriction/edit',
|
|
|
|
'ConduitAPI_phriction_history_Method' => 'applications/conduit/method/phriction/history',
|
|
|
|
'ConduitAPI_phriction_info_Method' => 'applications/conduit/method/phriction/info',
|
2012-01-18 01:29:35 +01:00
|
|
|
'ConduitAPI_project_Method' => 'applications/conduit/method/project/base',
|
|
|
|
'ConduitAPI_project_query_Method' => 'applications/conduit/method/project/query',
|
2012-02-03 01:42:29 +01:00
|
|
|
'ConduitAPI_remarkup_process_Method' => 'applications/conduit/method/remarkup/process',
|
2011-07-13 04:18:20 +02:00
|
|
|
'ConduitAPI_slowvote_info_Method' => 'applications/conduit/method/slowvote/info',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_user_Method' => 'applications/conduit/method/user/base',
|
2011-01-24 20:36:53 +01:00
|
|
|
'ConduitAPI_user_find_Method' => 'applications/conduit/method/user/find',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_user_info_Method' => 'applications/conduit/method/user/info',
|
2011-04-08 03:27:39 +02:00
|
|
|
'ConduitAPI_user_whoami_Method' => 'applications/conduit/method/user/whoami',
|
2011-01-24 18:00:29 +01:00
|
|
|
'ConduitException' => 'applications/conduit/protocol/exception',
|
2011-02-12 01:48:43 +01:00
|
|
|
'DarkConsoleConfigPlugin' => 'aphront/console/plugin/config',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsoleController' => 'aphront/console/controller',
|
|
|
|
'DarkConsoleCore' => 'aphront/console/core',
|
|
|
|
'DarkConsoleErrorLogPlugin' => 'aphront/console/plugin/errorlog',
|
2011-02-03 07:38:42 +01:00
|
|
|
'DarkConsoleErrorLogPluginAPI' => 'aphront/console/plugin/errorlog/api',
|
2011-09-30 21:54:17 +02:00
|
|
|
'DarkConsoleEventPlugin' => 'aphront/console/plugin/event',
|
|
|
|
'DarkConsoleEventPluginAPI' => 'aphront/console/plugin/event/api',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsolePlugin' => 'aphront/console/plugin/base',
|
|
|
|
'DarkConsoleRequestPlugin' => 'aphront/console/plugin/request',
|
|
|
|
'DarkConsoleServicesPlugin' => 'aphront/console/plugin/services',
|
|
|
|
'DarkConsoleXHProfPlugin' => 'aphront/console/plugin/xhprof',
|
|
|
|
'DarkConsoleXHProfPluginAPI' => 'aphront/console/plugin/xhprof/api',
|
2012-04-06 23:42:02 +02:00
|
|
|
'DatabaseConfigurationProvider' => 'applications/base/storage/configuration/base',
|
|
|
|
'DefaultDatabaseConfigurationProvider' => 'applications/base/storage/configuration/default',
|
2011-01-24 03:10:20 +01:00
|
|
|
'DifferentialAction' => 'applications/differential/constants/action',
|
Improve behavior when user submits a no-op action in Differential
Summary:
See T730 and the slightly-less-pretty version of this in D1398.
When a user takes an action in Differential that has no effect (for instance,
accepting an already-accepted revision), prompt them:
Action Has No Effect
You can not accept this revision because it has already been accepted.
Do you want to post the feedback anyway, as a normal comment?
[Cancel] [Post as Comment]
If they have no comment text, the dialog only says "Cancel".
I think this is probably the best way to balance all the concerns here -- it
might occasionally be a little annoying, but that should be rare, and it should
never be confusing (the current workflow is extremely confusing).
This also fixes the issue where you can add all sorts of CCs who are already
part of the revision, either explicitly or via mentions.
Test Plan:
Posted some has-effect and has-no-effect comments, made different
choices in the dialog, everything seems to work OK?
Reviewers: vrana, btrahan, jungejason
Reviewed By: vrana
CC: aran, vrana
Maniphest Tasks: T730
Differential Revision: https://secure.phabricator.com/D1403
2012-01-14 20:39:22 +01:00
|
|
|
'DifferentialActionHasNoEffectException' => 'applications/differential/exception/noeffect',
|
2011-01-30 20:02:22 +01:00
|
|
|
'DifferentialAddCommentView' => 'applications/differential/view/addcomment',
|
2011-09-14 19:59:52 +02:00
|
|
|
'DifferentialAffectedPath' => 'applications/differential/storage/affectedpath',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialApplyPatchFieldSpecification' => 'applications/differential/field/specification/applypatch',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialArcanistProjectFieldSpecification' => 'applications/differential/field/specification/arcanistproject',
|
2012-03-07 00:10:35 +01:00
|
|
|
'DifferentialAuditorsFieldSpecification' => 'applications/differential/field/specification/auditors',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialAuthorFieldSpecification' => 'applications/differential/field/specification/author',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialAuxiliaryField' => 'applications/differential/storage/auxiliaryfield',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialBlameRevisionFieldSpecification' => 'applications/differential/field/specification/blamerev',
|
2012-02-07 01:34:25 +01:00
|
|
|
'DifferentialBranchFieldSpecification' => 'applications/differential/field/specification/branch',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialCCWelcomeMail' => 'applications/differential/mail/ccwelcome',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialCCsFieldSpecification' => 'applications/differential/field/specification/ccs',
|
2011-01-24 03:10:20 +01:00
|
|
|
'DifferentialChangeType' => 'applications/differential/constants/changetype',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialChangeset' => 'applications/differential/storage/changeset',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialChangesetDetailView' => 'applications/differential/view/changesetdetailview',
|
2011-01-25 20:57:47 +01:00
|
|
|
'DifferentialChangesetListView' => 'applications/differential/view/changesetlistview',
|
2011-01-25 00:52:35 +01:00
|
|
|
'DifferentialChangesetParser' => 'applications/differential/parser/changeset',
|
|
|
|
'DifferentialChangesetViewController' => 'applications/differential/controller/changesetview',
|
2011-01-30 19:37:36 +01:00
|
|
|
'DifferentialComment' => 'applications/differential/storage/comment',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentEditor' => 'applications/differential/editor/comment',
|
|
|
|
'DifferentialCommentMail' => 'applications/differential/mail/comment',
|
2011-02-01 03:05:20 +01:00
|
|
|
'DifferentialCommentPreviewController' => 'applications/differential/controller/commentpreview',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentSaveController' => 'applications/differential/controller/commentsave',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialCommitsFieldSpecification' => 'applications/differential/field/specification/commits',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialController' => 'applications/differential/controller/base',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDAO' => 'applications/differential/storage/base',
|
2012-02-20 14:38:21 +01:00
|
|
|
'DifferentialDateCreatedFieldSpecification' => 'applications/differential/field/specification/datecreated',
|
|
|
|
'DifferentialDateModifiedFieldSpecification' => 'applications/differential/field/specification/datemodified',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialDefaultFieldSelector' => 'applications/differential/field/selector/default',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialDependenciesFieldSpecification' => 'applications/differential/field/specification/dependencies',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDiff' => 'applications/differential/storage/diff',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialDiffContentMail' => 'applications/differential/mail/diffcontent',
|
2011-02-05 21:20:18 +01:00
|
|
|
'DifferentialDiffCreateController' => 'applications/differential/controller/diffcreate',
|
2011-01-24 21:07:34 +01:00
|
|
|
'DifferentialDiffProperty' => 'applications/differential/storage/diffproperty',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialDiffTableOfContentsView' => 'applications/differential/view/difftableofcontents',
|
|
|
|
'DifferentialDiffViewController' => 'applications/differential/controller/diffview',
|
Improve behavior when user submits a no-op action in Differential
Summary:
See T730 and the slightly-less-pretty version of this in D1398.
When a user takes an action in Differential that has no effect (for instance,
accepting an already-accepted revision), prompt them:
Action Has No Effect
You can not accept this revision because it has already been accepted.
Do you want to post the feedback anyway, as a normal comment?
[Cancel] [Post as Comment]
If they have no comment text, the dialog only says "Cancel".
I think this is probably the best way to balance all the concerns here -- it
might occasionally be a little annoying, but that should be rare, and it should
never be confusing (the current workflow is extremely confusing).
This also fixes the issue where you can add all sorts of CCs who are already
part of the revision, either explicitly or via mentions.
Test Plan:
Posted some has-effect and has-no-effect comments, made different
choices in the dialog, everything seems to work OK?
Reviewers: vrana, btrahan, jungejason
Reviewed By: vrana
CC: aran, vrana
Maniphest Tasks: T730
Differential Revision: https://secure.phabricator.com/D1403
2012-01-14 20:39:22 +01:00
|
|
|
'DifferentialException' => 'applications/differential/exception/base',
|
2011-05-01 04:40:05 +02:00
|
|
|
'DifferentialExceptionMail' => 'applications/differential/mail/exception',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialExportPatchFieldSpecification' => 'applications/differential/field/specification/exportpatch',
|
|
|
|
'DifferentialFieldDataNotAvailableException' => 'applications/differential/field/exception/notavailable',
|
Drive Differential commit message parsing through extensible fields
Summary:
I think this is the last major step -- use the fields to parse commit messages,
not a hard-coded list of stuff. This adds two primary methods to fields, one to
get all the labels they'll parse (so we can do "CC" and "CCs" and treat them as
the same field) and one to parse the string into a canonical representation
(e.g., lookup reviewers and such).
You'll need to impelement the one block of task-specific stuff I removed in
Facebook's task field:
list($pre_comment) = split(' -- ', $data);
$data = array_filter(preg_split('/[^\d]+/', $pre_comment));
foreach ($data as $k => $v) {
$data[$k] = (int)$v;
}
$data = array_unique($data);
break;
Otherwise I think this is clean.
Test Plan:
- Called the conduit method with various commit messages, parsed fields/errors
seemed correct.
- "arc diff"'d this diff onto localhost, then updated it.
- "arc amend"'d this diff.
Reviewers: jungejason, tuomaspelkonen, aran
Reviewed By: jungejason
CC: aran, jungejason, epriestley
Differential Revision: 829
2011-08-18 21:08:18 +02:00
|
|
|
'DifferentialFieldParseException' => 'applications/differential/field/exception/parse',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialFieldSelector' => 'applications/differential/field/selector/base',
|
|
|
|
'DifferentialFieldSpecification' => 'applications/differential/field/specification/base',
|
2011-08-10 22:46:01 +02:00
|
|
|
'DifferentialFieldSpecificationIncompleteException' => 'applications/differential/field/exception/incomplete',
|
|
|
|
'DifferentialFieldValidationException' => 'applications/differential/field/exception/validation',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialGitSVNIDFieldSpecification' => 'applications/differential/field/specification/gitsvnid',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialHostFieldSpecification' => 'applications/differential/field/specification/host',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialHunk' => 'applications/differential/storage/hunk',
|
2011-02-02 00:52:04 +01:00
|
|
|
'DifferentialInlineComment' => 'applications/differential/storage/inlinecomment',
|
2011-02-02 01:42:36 +01:00
|
|
|
'DifferentialInlineCommentEditController' => 'applications/differential/controller/inlinecommentedit',
|
2012-02-29 23:28:48 +01:00
|
|
|
'DifferentialInlineCommentEditView' => 'applications/differential/view/inlinecommentedit',
|
2011-02-03 04:38:43 +01:00
|
|
|
'DifferentialInlineCommentPreviewController' => 'applications/differential/controller/inlinecommentpreview',
|
2011-02-02 01:42:36 +01:00
|
|
|
'DifferentialInlineCommentView' => 'applications/differential/view/inlinecomment',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialLinesFieldSpecification' => 'applications/differential/field/specification/lines',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialLintFieldSpecification' => 'applications/differential/field/specification/lint',
|
2011-01-24 03:10:20 +01:00
|
|
|
'DifferentialLintStatus' => 'applications/differential/constants/lintstatus',
|
2011-08-30 20:34:07 +02:00
|
|
|
'DifferentialLocalCommitsView' => 'applications/differential/view/localcommits',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialMail' => 'applications/differential/mail/base',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialManiphestTasksFieldSpecification' => 'applications/differential/field/specification/maniphesttasks',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialNewDiffMail' => 'applications/differential/mail/newdiff',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialPathFieldSpecification' => 'applications/differential/field/specification/path',
|
2011-06-08 21:39:03 +02:00
|
|
|
'DifferentialPrimaryPaneView' => 'applications/differential/view/primarypane',
|
2011-05-01 04:40:05 +02:00
|
|
|
'DifferentialReplyHandler' => 'applications/differential/replyhandler',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialRevertPlanFieldSpecification' => 'applications/differential/field/specification/revertplan',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialReviewRequestMail' => 'applications/differential/mail/reviewrequest',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialReviewedByFieldSpecification' => 'applications/differential/field/specification/reviewedby',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialReviewersFieldSpecification' => 'applications/differential/field/specification/reviewers',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialRevision' => 'applications/differential/storage/revision',
|
2011-01-30 19:37:36 +01:00
|
|
|
'DifferentialRevisionCommentListView' => 'applications/differential/view/revisioncommentlist',
|
|
|
|
'DifferentialRevisionCommentView' => 'applications/differential/view/revisioncomment',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialRevisionControlSystem' => 'applications/differential/constants/revisioncontrolsystem',
|
2011-04-13 00:57:29 +02:00
|
|
|
'DifferentialRevisionDetailRenderer' => 'applications/differential/controller/customrenderer',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionDetailView' => 'applications/differential/view/revisiondetail',
|
2011-01-25 22:26:09 +01:00
|
|
|
'DifferentialRevisionEditController' => 'applications/differential/controller/revisionedit',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialRevisionEditor' => 'applications/differential/editor/revision',
|
Emit full URIs to identify Differential revisions
Summary:
- Previously, used IDs like "33" to match a commit to a Differential revision.
This has a namespacing problem because we now have an arbitrarily large number
of Phabricator installs in the world, and they may want to track commits from
other installs.
- In Differential, parse raw IDs or full URIs. Emit only full URIs.
- In Repositories, parse only full URIs.
- This might cause a few commits to not be picked up in rare circumstances.
Users can fix them with "arc mark-committed". This should be exceedingly rare
because of hash matching.
- There are some caveats for reparsing older repositories, see comments
inline. I don't think there's much broad impact here.
Test Plan:
- Created a new revision, got a full URI.
- Updated revision, worked correctly.
- Ran unit tests.
- Monkeyed with "Differential Revision" field.
- Reviewers: btrahan, jungejason
Reviewers: btrahan, jungejason
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Maniphest Tasks: T54, T692
Differential Revision: 1250
2011-12-21 00:40:24 +01:00
|
|
|
'DifferentialRevisionIDFieldParserTestCase' => 'applications/differential/field/specification/revisionid/__tests__',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialRevisionIDFieldSpecification' => 'applications/differential/field/specification/revisionid',
|
2011-01-26 00:19:06 +01:00
|
|
|
'DifferentialRevisionListController' => 'applications/differential/controller/revisionlist',
|
2011-01-27 20:35:04 +01:00
|
|
|
'DifferentialRevisionListData' => 'applications/differential/data/revisionlist',
|
2011-10-02 20:42:41 +02:00
|
|
|
'DifferentialRevisionListView' => 'applications/differential/view/revisionlist',
|
2011-10-02 21:03:16 +02:00
|
|
|
'DifferentialRevisionQuery' => 'applications/differential/query/revision',
|
2012-02-19 05:16:35 +01:00
|
|
|
'DifferentialRevisionStatsController' => 'applications/differential/controller/revisionstats',
|
|
|
|
'DifferentialRevisionStatsView' => 'applications/differential/view/revisionstats',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialRevisionStatusFieldSpecification' => 'applications/differential/field/specification/revisionstatus',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionUpdateHistoryView' => 'applications/differential/view/revisionupdatehistory',
|
|
|
|
'DifferentialRevisionViewController' => 'applications/differential/controller/revisionview',
|
2011-02-19 23:36:13 +01:00
|
|
|
'DifferentialSubscribeController' => 'applications/differential/controller/subscribe',
|
2011-08-14 23:28:08 +02:00
|
|
|
'DifferentialSummaryFieldSpecification' => 'applications/differential/field/specification/summary',
|
2011-04-22 02:53:18 +02:00
|
|
|
'DifferentialTasksAttacher' => 'applications/differential/tasks',
|
2011-08-14 23:28:08 +02:00
|
|
|
'DifferentialTestPlanFieldSpecification' => 'applications/differential/field/specification/testplan',
|
|
|
|
'DifferentialTitleFieldSpecification' => 'applications/differential/field/specification/title',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialUnitFieldSpecification' => 'applications/differential/field/specification/unit',
|
2011-01-24 03:10:20 +01:00
|
|
|
'DifferentialUnitStatus' => 'applications/differential/constants/unitstatus',
|
2011-06-09 01:16:59 +02:00
|
|
|
'DifferentialUnitTestResult' => 'applications/differential/constants/unittestresult',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionBranchInformation' => 'applications/diffusion/data/branch',
|
|
|
|
'DiffusionBranchQuery' => 'applications/diffusion/query/branch/base',
|
|
|
|
'DiffusionBranchTableView' => 'applications/diffusion/view/branchtable',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionBrowseController' => 'applications/diffusion/controller/browse',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionBrowseFileController' => 'applications/diffusion/controller/file',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionBrowseQuery' => 'applications/diffusion/query/browse/base',
|
|
|
|
'DiffusionBrowseTableView' => 'applications/diffusion/view/browsetable',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionChangeController' => 'applications/diffusion/controller/change',
|
2012-02-24 23:14:39 +01:00
|
|
|
'DiffusionCommentListView' => 'applications/diffusion/view/commentlist',
|
|
|
|
'DiffusionCommentView' => 'applications/diffusion/view/comment',
|
2011-03-11 18:34:22 +01:00
|
|
|
'DiffusionCommitChangeTableView' => 'applications/diffusion/view/commitchangetable',
|
|
|
|
'DiffusionCommitController' => 'applications/diffusion/controller/commit',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionCommitParentsQuery' => 'applications/diffusion/query/parents/base',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionCommitTagsQuery' => 'applications/diffusion/query/committags/base',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionContainsQuery' => 'applications/diffusion/query/contains/base',
|
2011-03-08 00:13:36 +01:00
|
|
|
'DiffusionController' => 'applications/diffusion/controller/base',
|
2011-03-31 02:36:16 +02:00
|
|
|
'DiffusionDiffController' => 'applications/diffusion/controller/diff',
|
|
|
|
'DiffusionDiffQuery' => 'applications/diffusion/query/diff/base',
|
2012-02-01 19:59:20 +01:00
|
|
|
'DiffusionEmptyResultView' => 'applications/diffusion/view/emptyresult',
|
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' => 'applications/diffusion/controller/external',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionFileContent' => 'applications/diffusion/data/filecontent',
|
|
|
|
'DiffusionFileContentQuery' => 'applications/diffusion/query/filecontent/base',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionGitBranchQuery' => 'applications/diffusion/query/branch/git',
|
2011-12-22 21:24:12 +01:00
|
|
|
'DiffusionGitBranchQueryTestCase' => 'applications/diffusion/query/branch/git/__tests__',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionGitBrowseQuery' => 'applications/diffusion/query/browse/git',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionGitCommitParentsQuery' => 'applications/diffusion/query/parents/git',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionGitCommitTagsQuery' => 'applications/diffusion/query/committags/git',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionGitContainsQuery' => 'applications/diffusion/query/contains/git',
|
2011-03-31 03:17:36 +02:00
|
|
|
'DiffusionGitDiffQuery' => 'applications/diffusion/query/diff/git',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionGitFileContentQuery' => 'applications/diffusion/query/filecontent/git',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionGitHistoryQuery' => 'applications/diffusion/query/history/git',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionGitLastModifiedQuery' => 'applications/diffusion/query/lastmodified/git',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionGitMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/git',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionGitRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/git',
|
2011-03-08 23:29:02 +01:00
|
|
|
'DiffusionGitRequest' => 'applications/diffusion/request/git',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionGitTagListQuery' => 'applications/diffusion/query/taglist/git',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionHistoryController' => 'applications/diffusion/controller/history',
|
|
|
|
'DiffusionHistoryQuery' => 'applications/diffusion/query/history/base',
|
|
|
|
'DiffusionHistoryTableView' => 'applications/diffusion/view/historytable',
|
2011-03-08 00:13:36 +01:00
|
|
|
'DiffusionHomeController' => 'applications/diffusion/controller/home',
|
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' => 'applications/diffusion/controller/inline',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionLastModifiedController' => 'applications/diffusion/controller/lastmodified',
|
|
|
|
'DiffusionLastModifiedQuery' => 'applications/diffusion/query/lastmodified/base',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialBranchQuery' => 'applications/diffusion/query/branch/mercurial',
|
|
|
|
'DiffusionMercurialBrowseQuery' => 'applications/diffusion/query/browse/mercurial',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionMercurialCommitParentsQuery' => 'applications/diffusion/query/parents/mercurial',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionMercurialCommitTagsQuery' => 'applications/diffusion/query/committags/mercurial',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionMercurialContainsQuery' => 'applications/diffusion/query/contains/mercurial',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialDiffQuery' => 'applications/diffusion/query/diff/mercurial',
|
|
|
|
'DiffusionMercurialFileContentQuery' => 'applications/diffusion/query/filecontent/mercurial',
|
|
|
|
'DiffusionMercurialHistoryQuery' => 'applications/diffusion/query/history/mercurial',
|
|
|
|
'DiffusionMercurialLastModifiedQuery' => 'applications/diffusion/query/lastmodified/mercurial',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMercurialMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/mercurial',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionMercurialRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/mercurial',
|
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' => 'applications/diffusion/request/mercurial',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionMercurialTagListQuery' => 'applications/diffusion/query/taglist/mercurial',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/base',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionPathChange' => 'applications/diffusion/data/pathchange',
|
2011-03-14 00:19:39 +01:00
|
|
|
'DiffusionPathChangeQuery' => 'applications/diffusion/query/pathchange/base',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathCompleteController' => 'applications/diffusion/controller/pathcomplete',
|
2011-09-14 19:59:52 +02:00
|
|
|
'DiffusionPathIDQuery' => 'applications/diffusion/query/pathid/base',
|
2012-03-20 03:56:06 +01:00
|
|
|
'DiffusionPathQuery' => 'applications/diffusion/query/path',
|
2011-09-14 20:23:39 +02:00
|
|
|
'DiffusionPathQueryTestCase' => 'applications/diffusion/query/pathid/base/__tests__',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathValidateController' => 'applications/diffusion/controller/pathvalidate',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionQuery' => 'applications/diffusion/query/base',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/base',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionRepositoryController' => 'applications/diffusion/controller/repository',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionRepositoryPath' => 'applications/diffusion/data/repositorypath',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionRepositoryTag' => 'applications/diffusion/tag',
|
2011-03-08 23:29:02 +01:00
|
|
|
'DiffusionRequest' => 'applications/diffusion/request/base',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionSvnBrowseQuery' => 'applications/diffusion/query/browse/svn',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionSvnCommitParentsQuery' => 'applications/diffusion/query/parents/svn',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionSvnCommitTagsQuery' => 'applications/diffusion/query/committags/svn',
|
2012-03-24 20:52:14 +01:00
|
|
|
'DiffusionSvnContainsQuery' => 'applications/diffusion/query/contains/svn',
|
2011-03-31 02:36:16 +02:00
|
|
|
'DiffusionSvnDiffQuery' => 'applications/diffusion/query/diff/svn',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionSvnFileContentQuery' => 'applications/diffusion/query/filecontent/svn',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionSvnHistoryQuery' => 'applications/diffusion/query/history/svn',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionSvnLastModifiedQuery' => 'applications/diffusion/query/lastmodified/svn',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionSvnMergedCommitsQuery' => 'applications/diffusion/query/mergedcommits/svn',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionSvnRenameHistoryQuery' => 'applications/diffusion/query/renamehistory/svn',
|
2011-03-23 03:34:47 +01:00
|
|
|
'DiffusionSvnRequest' => 'applications/diffusion/request/svn',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionSvnTagListQuery' => 'applications/diffusion/query/taglist/svn',
|
2011-09-05 19:43:24 +02:00
|
|
|
'DiffusionSymbolController' => 'applications/diffusion/controller/symbol',
|
|
|
|
'DiffusionSymbolQuery' => 'applications/diffusion/query/symbol',
|
2012-04-19 18:39:19 +02:00
|
|
|
'DiffusionTagListController' => 'applications/diffusion/controller/taglist',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionTagListQuery' => 'applications/diffusion/query/taglist/base',
|
|
|
|
'DiffusionTagListView' => 'applications/diffusion/view/taglist',
|
Fix many encoding and architecture problems in Diffusion request and URI handling
Summary:
Diffusion request/uri handling is currently a big, hastily ported mess. In particular, it has:
- Tons and tons of duplicated code.
- Bugs with handling unusual branch and file names.
- An excessively large (and yet insufficiently expressive) API on DiffusionRequest, including a nonsensical concrete base class.
- Other tools were doing hacky things like passing ":" branch names.
This diff attempts to fix these issues.
- Make the base class abstract (it was concrete ONLY for "/diffusion/").
- Move all URI generation to DiffusionRequest. Make the core static. Add unit tests.
- Delete the 300 copies of URI generation code throughout Diffusion.
- Move all URI parsing to DiffusionRequest. Make the core static. Add unit tests.
- Add an appropriate static initializer for other callers.
- Convert all code calling `newFromAphrontRequestDictionary` outside of Diffusion to the new `newFromDictionary` API.
- Refactor static initializers to be sensibly-sized.
- Refactor derived DiffusionRequest classes to remove duplicated code.
- Properly encode branch names (fixes branches with "/", see <https://github.com/facebook/phabricator/issues/100>).
- Properly encode path names (fixes issues in D1742).
- Properly escape delimiter characters ";" and "$" in path names so files like "$100" are not interpreted as "line 100".
- Fix a couple warnings.
- Fix a couple lint issues.
- Fix a bug where we would not parse filenames with spaces in them correctly in the Git browse query.
- Fix a bug where Git change queries would fail unnecessarily.
- Provide or improve some documentation.
This thing is pretty gigantic but also kind of hard to split up. If it's unreasonably difficult to review, let me know and I can take a stab at it though.
This supplants D1742.
Test Plan:
- Used home, repository, branch, browse, change, history, diff (ajax), lastmodified (ajax) views of Diffusion.
- Used Owners typeaheads and search.
- Used diffusion.getrecentcommitsbypath method.
- Pushed a change to an absurdly-named file on an absurdly-named branch, everything worked properly.
{F9185}
Reviewers: nh, vrana, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1921
2012-03-20 03:52:14 +01:00
|
|
|
'DiffusionURITestCase' => 'applications/diffusion/request/base/__tests__',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionView' => 'applications/diffusion/view/base',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockAllocator' => 'applications/drydock/allocator/resource',
|
2012-01-24 01:58:38 +01:00
|
|
|
'DrydockAllocatorWorker' => 'applications/drydock/allocator/worker',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockApacheWebrootBlueprint' => 'applications/drydock/blueprint/webroot/apache',
|
|
|
|
'DrydockApacheWebrootInterface' => 'applications/drydock/interface/webroot/apache',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockBlueprint' => 'applications/drydock/blueprint/base',
|
|
|
|
'DrydockCommandInterface' => 'applications/drydock/interface/command/base',
|
|
|
|
'DrydockConstants' => 'applications/drydock/constants/base',
|
|
|
|
'DrydockController' => 'applications/drydock/controller/base',
|
|
|
|
'DrydockDAO' => 'applications/drydock/storage/base',
|
|
|
|
'DrydockEC2HostBlueprint' => 'applications/drydock/blueprint/ec2host',
|
|
|
|
'DrydockInterface' => 'applications/drydock/interface/base',
|
|
|
|
'DrydockLease' => 'applications/drydock/storage/lease',
|
|
|
|
'DrydockLeaseListController' => 'applications/drydock/controller/leaselist',
|
|
|
|
'DrydockLeaseStatus' => 'applications/drydock/constants/leasestatus',
|
|
|
|
'DrydockLocalCommandInterface' => 'applications/drydock/interface/command/local',
|
|
|
|
'DrydockLocalHostBlueprint' => 'applications/drydock/blueprint/localhost',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockLog' => 'applications/drydock/storage/log',
|
|
|
|
'DrydockLogController' => 'applications/drydock/controller/log',
|
|
|
|
'DrydockLogQuery' => 'applications/drydock/query/log',
|
|
|
|
'DrydockPhabricatorApplicationBlueprint' => 'applications/drydock/blueprint/application/phabricator',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockRemoteHostBlueprint' => 'applications/drydock/blueprint/remotehost',
|
|
|
|
'DrydockResource' => 'applications/drydock/storage/resource',
|
|
|
|
'DrydockResourceAllocateController' => 'applications/drydock/controller/resourceallocate',
|
|
|
|
'DrydockResourceListController' => 'applications/drydock/controller/resourcelist',
|
|
|
|
'DrydockResourceStatus' => 'applications/drydock/constants/resourcestatus',
|
|
|
|
'DrydockSSHCommandInterface' => 'applications/drydock/interface/command/ssh',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockWebrootInterface' => 'applications/drydock/interface/webroot/base',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldAction' => 'applications/herald/storage/action',
|
|
|
|
'HeraldActionConfig' => 'applications/herald/config/action',
|
|
|
|
'HeraldApplyTranscript' => 'applications/herald/storage/transcript/apply',
|
2011-04-04 08:23:36 +02:00
|
|
|
'HeraldCommitAdapter' => 'applications/herald/adapter/commit',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldCondition' => 'applications/herald/storage/condition',
|
|
|
|
'HeraldConditionConfig' => 'applications/herald/config/condition',
|
|
|
|
'HeraldConditionTranscript' => 'applications/herald/storage/transcript/condition',
|
|
|
|
'HeraldContentTypeConfig' => 'applications/herald/config/contenttype',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldController' => 'applications/herald/controller/base',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldDAO' => 'applications/herald/storage/base',
|
2011-03-24 19:07:36 +01:00
|
|
|
'HeraldDeleteController' => 'applications/herald/controller/delete',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldDifferentialRevisionAdapter' => 'applications/herald/adapter/differential',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldDryRunAdapter' => 'applications/herald/adapter/dryrun',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'HeraldEditLogQuery' => 'applications/herald/query/log',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldEffect' => 'applications/herald/engine/effect',
|
|
|
|
'HeraldEngine' => 'applications/herald/engine/engine',
|
|
|
|
'HeraldFieldConfig' => 'applications/herald/config/field',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldHomeController' => 'applications/herald/controller/home',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldInvalidConditionException' => 'applications/herald/engine/engine/exception',
|
|
|
|
'HeraldInvalidFieldException' => 'applications/herald/engine/engine/exception',
|
2011-03-22 22:34:38 +01:00
|
|
|
'HeraldNewController' => 'applications/herald/controller/new',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldObjectAdapter' => 'applications/herald/adapter/base',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldObjectTranscript' => 'applications/herald/storage/transcript/object',
|
|
|
|
'HeraldRecursiveConditionsException' => 'applications/herald/engine/engine/exception',
|
2011-05-28 00:52:26 +02:00
|
|
|
'HeraldRepetitionPolicyConfig' => 'applications/herald/config/repetitionpolicy',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldRule' => 'applications/herald/storage/rule',
|
2011-03-22 23:27:52 +01:00
|
|
|
'HeraldRuleController' => 'applications/herald/controller/rule',
|
2012-01-30 20:51:23 +01:00
|
|
|
'HeraldRuleEdit' => 'applications/herald/storage/edithistory',
|
|
|
|
'HeraldRuleEditHistoryController' => 'applications/herald/controller/edithistory',
|
|
|
|
'HeraldRuleEditHistoryView' => 'applications/herald/view/edithistory',
|
2011-11-06 09:07:04 +01:00
|
|
|
'HeraldRuleListView' => 'applications/herald/view/rulelist',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'HeraldRuleQuery' => 'applications/herald/query/rule',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldRuleTranscript' => 'applications/herald/storage/transcript/rule',
|
2012-01-14 00:24:56 +01:00
|
|
|
'HeraldRuleTypeConfig' => 'applications/herald/config/ruletype',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldTestConsoleController' => 'applications/herald/controller/test',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldTranscript' => 'applications/herald/storage/transcript/base',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldTranscriptController' => 'applications/herald/controller/transcript',
|
|
|
|
'HeraldTranscriptListController' => 'applications/herald/controller/transcriptlist',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldValueTypeConfig' => 'applications/herald/config/valuetype',
|
2011-01-31 20:55:26 +01:00
|
|
|
'Javelin' => 'infrastructure/javelin/api',
|
2011-09-07 23:01:13 +02:00
|
|
|
'JavelinReactorExample' => 'applications/uiexample/examples/reactor',
|
|
|
|
'JavelinViewExample' => 'applications/uiexample/examples/client',
|
|
|
|
'JavelinViewExampleServerView' => 'applications/uiexample/examples/client',
|
2011-01-16 22:51:39 +01:00
|
|
|
'LiskDAO' => 'storage/lisk/dao',
|
2012-03-08 23:35:12 +01:00
|
|
|
'LiskEphemeralObjectException' => 'storage/lisk/dao',
|
2011-04-30 19:11:59 +02:00
|
|
|
'LiskIsolationTestCase' => 'storage/lisk/dao/__tests__',
|
|
|
|
'LiskIsolationTestDAO' => 'storage/lisk/dao/__tests__',
|
|
|
|
'LiskIsolationTestDAOException' => 'storage/lisk/dao/__tests__',
|
2011-12-17 22:27:11 +01:00
|
|
|
'ManiphestAction' => 'applications/maniphest/constants/action',
|
2011-07-27 18:49:50 +02:00
|
|
|
'ManiphestAuxiliaryFieldDefaultSpecification' => 'applications/maniphest/auxiliaryfield/default',
|
|
|
|
'ManiphestAuxiliaryFieldSpecification' => 'applications/maniphest/auxiliaryfield/base',
|
|
|
|
'ManiphestAuxiliaryFieldTypeException' => 'applications/maniphest/auxiliaryfield/typeexception',
|
|
|
|
'ManiphestAuxiliaryFieldValidationException' => 'applications/maniphest/auxiliaryfield/validationexception',
|
2012-02-24 22:00:48 +01:00
|
|
|
'ManiphestBatchEditController' => 'applications/maniphest/controller/batch',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestConstants' => 'applications/maniphest/constants/base',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestController' => 'applications/maniphest/controller/base',
|
|
|
|
'ManiphestDAO' => 'applications/maniphest/storage/base',
|
2011-07-27 18:49:50 +02:00
|
|
|
'ManiphestDefaultTaskExtensions' => 'applications/maniphest/extensions/task',
|
2012-02-29 06:07:12 +01:00
|
|
|
'ManiphestExportController' => 'applications/maniphest/controller/export',
|
2011-05-10 01:31:26 +02:00
|
|
|
'ManiphestReplyHandler' => 'applications/maniphest/replyhandler',
|
2012-02-08 18:47:14 +01:00
|
|
|
'ManiphestReportController' => 'applications/maniphest/controller/report',
|
2012-04-10 18:46:04 +02:00
|
|
|
'ManiphestSavedQuery' => 'applications/maniphest/storage/savedquery',
|
|
|
|
'ManiphestSavedQueryDeleteController' => 'applications/maniphest/controller/savedquerydelete',
|
|
|
|
'ManiphestSavedQueryEditController' => 'applications/maniphest/controller/savedqueryedit',
|
|
|
|
'ManiphestSavedQueryListController' => 'applications/maniphest/controller/savedquerylist',
|
2012-04-02 21:12:04 +02:00
|
|
|
'ManiphestSubpriorityController' => 'applications/maniphest/controller/subpriority',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTask' => 'applications/maniphest/storage/task',
|
2011-07-26 00:34:56 +02:00
|
|
|
'ManiphestTaskAuxiliaryStorage' => 'applications/maniphest/storage/auxiliary',
|
2011-05-21 03:56:18 +02:00
|
|
|
'ManiphestTaskDescriptionChangeController' => 'applications/maniphest/controller/descriptionchange',
|
2012-01-25 20:23:00 +01:00
|
|
|
'ManiphestTaskDescriptionPreviewController' => 'applications/maniphest/controller/descriptionpreview',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskDetailController' => 'applications/maniphest/controller/taskdetail',
|
2011-02-20 23:15:53 +01:00
|
|
|
'ManiphestTaskEditController' => 'applications/maniphest/controller/taskedit',
|
2011-08-05 18:44:43 +02:00
|
|
|
'ManiphestTaskExtensions' => 'applications/maniphest/extensions/base',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskListController' => 'applications/maniphest/controller/tasklist',
|
|
|
|
'ManiphestTaskListView' => 'applications/maniphest/view/tasklist',
|
2011-05-28 23:13:12 +02:00
|
|
|
'ManiphestTaskOwner' => 'applications/maniphest/constants/owner',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskPriority' => 'applications/maniphest/constants/priority',
|
2011-06-30 01:16:33 +02:00
|
|
|
'ManiphestTaskProject' => 'applications/maniphest/storage/taskproject',
|
2012-04-02 19:27:31 +02:00
|
|
|
'ManiphestTaskProjectsView' => 'applications/maniphest/view/taskprojects',
|
2011-06-30 01:16:33 +02:00
|
|
|
'ManiphestTaskQuery' => 'applications/maniphest/query',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskStatus' => 'applications/maniphest/constants/status',
|
2011-07-07 19:24:49 +02:00
|
|
|
'ManiphestTaskSubscriber' => 'applications/maniphest/storage/subscriber',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskSummaryView' => 'applications/maniphest/view/tasksummary',
|
|
|
|
'ManiphestTransaction' => 'applications/maniphest/storage/transaction',
|
|
|
|
'ManiphestTransactionDetailView' => 'applications/maniphest/view/transactiondetail',
|
|
|
|
'ManiphestTransactionEditor' => 'applications/maniphest/editor/transaction',
|
|
|
|
'ManiphestTransactionListView' => 'applications/maniphest/view/transactionlist',
|
2011-05-10 17:29:28 +02:00
|
|
|
'ManiphestTransactionPreviewController' => 'applications/maniphest/controller/transactionpreview',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTransactionSaveController' => 'applications/maniphest/controller/transactionsave',
|
|
|
|
'ManiphestTransactionType' => 'applications/maniphest/constants/transactiontype',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestView' => 'applications/maniphest/view/base',
|
Add email preferences to receive fewer less-important notifications
Summary:
A few similar requests have come in across several tools and use cases that I
think this does a reasonable job of resolving.
We currently send one email for each update an object receives, but these aren't
always appreciated:
- Asana does post-commit review via Differential, so the "committed" mails are
useless.
- Quora wants to make project category edits to bugs without spamming people
attached to them.
- Some users in general are very sensitive to email volumes, and this gives us
a good way to reduce the volumes without incurring the complexity of
delayed-send-batching.
The technical mechanism is basically:
- Mail may optionally have "mail tags", which indicate content in the mail
(e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which
contains a priority change, a CC change, and a comment).
- If a mail has tags, remove any recipients who have opted out of all the
tags.
- Some tags can't be opted out of via the UI, so this ensures that important
email is still delivered (e.g., cc + assign + comment is always delivered
because you can't opt out of "assign" or "comment").
Test Plan:
- Disabled all mail tags in the web UI.
- Used test console to send myself mail with an opt-outable tag, it was
immediately dropped.
- Used test console to send myself mail with an opt-outable tag and a custom
tag, it was delivered.
- Made Differential updates affecting CCs with and without comments, got
appropriate delivery.
- Made Maniphest updates affecting project, priority and CCs with and without
comments, got appropriate delivery.
- Verified mail headers in all cases.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, epriestley, moskov
Maniphest Tasks: T616, T855
Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
|
|
|
'MetaMTAConstants' => 'applications/metamta/constants/base',
|
|
|
|
'MetaMTANotificationType' => 'applications/metamta/constants/notificationtype',
|
2011-01-30 01:16:09 +01:00
|
|
|
'Phabricator404Controller' => 'applications/base/controller/404',
|
2012-03-07 05:14:03 +01:00
|
|
|
'PhabricatorAphlictTestPageController' => 'applications/notifications/controller/test',
|
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
|
|
|
'PhabricatorAuditActionConstants' => 'applications/audit/constants/action',
|
2012-02-25 00:04:53 +01:00
|
|
|
'PhabricatorAuditAddCommentController' => 'applications/audit/controller/addcomment',
|
Add Basic Auditing Functionalities
Summary:
add basic auditing functionalities. For the related commits for a
package, we detect the following conditions which might be suspicious to the
owners of the package:
* no revision specified
* revision not found
* author not match
* reviewedby not match
* owners not involved
* commit author not recognized
The owners of the package can change the status of the audit entries by
accepting it or specify concern.
The owner can turn on/off the auditing for a package.
Test Plan:
* verified that non-owner cannot see the details of the audit and cannot modify
it
* verified that all the audit reasons can be detected
* tested dropdown filtering and package search
* verified really normal change not detected
* verified accept/concern a commit
* tested enable/disable a package for auditing
* verified one audit applies to all <commit, packages> to the packages the
auditor owns
* verified that re-parsing a commit won't have effect if there exists a
relationship for <commit, package> already
Reviewers: epriestley, nh
Reviewed By: epriestley
CC: aran, benmathews, btrahan, mpodobnik, prithvi, TomL, epriestley
Differential Revision: 1242
2011-12-18 00:52:54 +01:00
|
|
|
'PhabricatorAuditComment' => 'applications/audit/storage/auditcomment',
|
2012-02-25 00:04:53 +01:00
|
|
|
'PhabricatorAuditCommentEditor' => 'applications/audit/editor/comment',
|
2012-02-29 06:10:39 +01:00
|
|
|
'PhabricatorAuditCommitListView' => 'applications/audit/view/commitlist',
|
|
|
|
'PhabricatorAuditCommitQuery' => 'applications/audit/query/commit',
|
2012-02-29 06:06:34 +01:00
|
|
|
'PhabricatorAuditCommitStatusConstants' => 'applications/audit/constants/commitstatus',
|
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' => 'applications/audit/controller/base',
|
|
|
|
'PhabricatorAuditDAO' => 'applications/audit/storage/base',
|
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
|
|
|
'PhabricatorAuditInlineComment' => 'applications/audit/storage/inlinecommment',
|
2012-02-24 22:02:14 +01:00
|
|
|
'PhabricatorAuditListController' => 'applications/audit/controller/list',
|
|
|
|
'PhabricatorAuditListView' => 'applications/audit/view/list',
|
2012-02-27 22:00:23 +01:00
|
|
|
'PhabricatorAuditPreviewController' => 'applications/audit/controller/preview',
|
2012-02-24 22:02:14 +01:00
|
|
|
'PhabricatorAuditQuery' => 'applications/audit/query/audit',
|
2012-02-27 21:57:57 +01:00
|
|
|
'PhabricatorAuditReplyHandler' => 'applications/audit/replyhandler',
|
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
|
|
|
'PhabricatorAuditStatusConstants' => 'applications/audit/constants/status',
|
2011-01-31 06:28:45 +01:00
|
|
|
'PhabricatorAuthController' => 'applications/auth/controller/base',
|
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' => 'applications/calendar/controller/browse',
|
|
|
|
'PhabricatorCalendarController' => 'applications/calendar/controller/base',
|
2012-03-13 05:39:05 +01:00
|
|
|
'PhabricatorChangesetResponse' => 'infrastructure/diff/response',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorChatLogChannelListController' => 'applications/chatlog/controller/channellist',
|
|
|
|
'PhabricatorChatLogChannelLogController' => 'applications/chatlog/controller/channellog',
|
|
|
|
'PhabricatorChatLogConstants' => 'applications/chatlog/constants/base',
|
|
|
|
'PhabricatorChatLogController' => 'applications/chatlog/controller/base',
|
|
|
|
'PhabricatorChatLogDAO' => 'applications/chatlog/storage/base',
|
|
|
|
'PhabricatorChatLogEvent' => 'applications/chatlog/storage/event',
|
|
|
|
'PhabricatorChatLogEventType' => 'applications/chatlog/constants/eventtype',
|
|
|
|
'PhabricatorChatLogQuery' => 'applications/chatlog/query',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitAPIController' => 'applications/conduit/controller/api',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitCertificateToken' => 'applications/conduit/storage/token',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitConnectionLog' => 'applications/conduit/storage/connectionlog',
|
|
|
|
'PhabricatorConduitConsoleController' => 'applications/conduit/controller/console',
|
|
|
|
'PhabricatorConduitController' => 'applications/conduit/controller/base',
|
|
|
|
'PhabricatorConduitDAO' => 'applications/conduit/storage/base',
|
|
|
|
'PhabricatorConduitLogController' => 'applications/conduit/controller/log',
|
|
|
|
'PhabricatorConduitMethodCallLog' => 'applications/conduit/storage/methodcalllog',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitTokenController' => 'applications/conduit/controller/token',
|
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
|
|
|
'PhabricatorContentSource' => 'applications/metamta/contentsource/source',
|
|
|
|
'PhabricatorContentSourceView' => 'applications/metamta/contentsource/view',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorController' => 'applications/base/controller/base',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorCountdownController' => 'applications/countdown/controller/base',
|
|
|
|
'PhabricatorCountdownDAO' => 'applications/countdown/storage/base',
|
|
|
|
'PhabricatorCountdownDeleteController' => 'applications/countdown/controller/delete',
|
|
|
|
'PhabricatorCountdownEditController' => 'applications/countdown/controller/edit',
|
|
|
|
'PhabricatorCountdownListController' => 'applications/countdown/controller/list',
|
|
|
|
'PhabricatorCountdownViewController' => 'applications/countdown/controller/view',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorDaemon' => 'infrastructure/daemon/base',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonCombinedLogController' => 'applications/daemon/controller/combined',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorDaemonConsoleController' => 'applications/daemon/controller/console',
|
2011-03-14 23:43:56 +01:00
|
|
|
'PhabricatorDaemonControl' => 'infrastructure/daemon/control',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorDaemonController' => 'applications/daemon/controller/base',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonDAO' => 'infrastructure/daemon/storage/base',
|
|
|
|
'PhabricatorDaemonLog' => 'infrastructure/daemon/storage/log',
|
|
|
|
'PhabricatorDaemonLogEvent' => 'infrastructure/daemon/storage/event',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonLogEventsView' => 'applications/daemon/view/daemonlogevents',
|
|
|
|
'PhabricatorDaemonLogListController' => 'applications/daemon/controller/loglist',
|
|
|
|
'PhabricatorDaemonLogListView' => 'applications/daemon/view/daemonloglist',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonLogViewController' => 'applications/daemon/controller/logview',
|
2011-03-14 23:43:56 +01:00
|
|
|
'PhabricatorDaemonReference' => 'infrastructure/daemon/control/reference',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorDaemonTimelineConsoleController' => 'applications/daemon/controller/timeline',
|
|
|
|
'PhabricatorDaemonTimelineEventController' => 'applications/daemon/controller/timelineevent',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorDefaultFileStorageEngineSelector' => 'applications/files/engineselector/default',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorDefaultSearchEngineSelector' => 'applications/search/selector/default',
|
2011-07-17 20:06:02 +02:00
|
|
|
'PhabricatorDifferenceEngine' => 'infrastructure/diff/engine',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryCategory' => 'applications/directory/storage/category',
|
|
|
|
'PhabricatorDirectoryCategoryDeleteController' => 'applications/directory/controller/categorydelete',
|
|
|
|
'PhabricatorDirectoryCategoryEditController' => 'applications/directory/controller/categoryedit',
|
Replace home directory list with a dashboard
Summary:
Rough cut that still needs a lot of polish, but replace the directory list with
more of a dashboard type thing:
- Show "Unbreak Now", triage-in-your-projects, and other stuff that you're
supposed to deal with, then feed.
- Move tools a click a way behind nav -- this also lets us put more stuff
there and subtools, etc., later.
- Remove tabs.
- Merge the category/item editing views.
- I also added a light blue wash to the side nav, not sure if I like that or
not.
Test Plan:
- Viewed all elements in empty and nonempty states.
- Viewed applications, edited items/categories.
Reviewers: btrahan, aran
Reviewed By: btrahan
CC: aran, epriestley, davidreuss
Maniphest Tasks: T21, T631
Differential Revision: https://secure.phabricator.com/D1574
2012-02-08 01:04:48 +01:00
|
|
|
'PhabricatorDirectoryCategoryViewController' => 'applications/directory/controller/categoryview',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryController' => 'applications/directory/controller/base',
|
|
|
|
'PhabricatorDirectoryDAO' => 'applications/directory/storage/base',
|
Replace home directory list with a dashboard
Summary:
Rough cut that still needs a lot of polish, but replace the directory list with
more of a dashboard type thing:
- Show "Unbreak Now", triage-in-your-projects, and other stuff that you're
supposed to deal with, then feed.
- Move tools a click a way behind nav -- this also lets us put more stuff
there and subtools, etc., later.
- Remove tabs.
- Merge the category/item editing views.
- I also added a light blue wash to the side nav, not sure if I like that or
not.
Test Plan:
- Viewed all elements in empty and nonempty states.
- Viewed applications, edited items/categories.
Reviewers: btrahan, aran
Reviewed By: btrahan
CC: aran, epriestley, davidreuss
Maniphest Tasks: T21, T631
Differential Revision: https://secure.phabricator.com/D1574
2012-02-08 01:04:48 +01:00
|
|
|
'PhabricatorDirectoryEditController' => 'applications/directory/controller/edit',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryItem' => 'applications/directory/storage/item',
|
|
|
|
'PhabricatorDirectoryItemDeleteController' => 'applications/directory/controller/itemdelete',
|
|
|
|
'PhabricatorDirectoryItemEditController' => 'applications/directory/controller/itemedit',
|
|
|
|
'PhabricatorDirectoryMainController' => 'applications/directory/controller/main',
|
2011-05-12 19:06:54 +02:00
|
|
|
'PhabricatorDisabledUserController' => 'applications/auth/controller/disabled',
|
2011-02-06 01:57:21 +01:00
|
|
|
'PhabricatorDraft' => 'applications/draft/storage/draft',
|
|
|
|
'PhabricatorDraftDAO' => 'applications/draft/storage/base',
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
|
|
|
'PhabricatorEdgeConfig' => 'infrastructure/edges/constants/config',
|
|
|
|
'PhabricatorEdgeConstants' => 'infrastructure/edges/constants/base',
|
|
|
|
'PhabricatorEdgeEditor' => 'infrastructure/edges/editor/edge',
|
|
|
|
'PhabricatorEdgeQuery' => 'infrastructure/edges/query/edge',
|
2011-01-31 20:55:26 +01:00
|
|
|
'PhabricatorEmailLoginController' => 'applications/auth/controller/email',
|
|
|
|
'PhabricatorEmailTokenController' => 'applications/auth/controller/emailtoken',
|
|
|
|
'PhabricatorEnv' => 'infrastructure/env',
|
2012-01-12 01:07:36 +01:00
|
|
|
'PhabricatorEnvTestCase' => 'infrastructure/env/__tests__',
|
2012-04-08 02:25:31 +02:00
|
|
|
'PhabricatorErrorExample' => 'applications/uiexample/examples/error',
|
2011-08-31 22:25:13 +02:00
|
|
|
'PhabricatorEvent' => 'infrastructure/events/event',
|
|
|
|
'PhabricatorEventEngine' => 'infrastructure/events/engine',
|
|
|
|
'PhabricatorEventType' => 'infrastructure/events/constant/type',
|
2011-12-18 00:50:37 +01:00
|
|
|
'PhabricatorFeedBuilder' => 'applications/feed/builder/feed',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedConstants' => 'applications/feed/constants/base',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedController' => 'applications/feed/controller/base',
|
|
|
|
'PhabricatorFeedDAO' => 'applications/feed/storage/base',
|
2011-07-10 03:03:59 +02:00
|
|
|
'PhabricatorFeedPublicStreamController' => 'applications/feed/controller/publicstream',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedQuery' => 'applications/feed/query',
|
|
|
|
'PhabricatorFeedStory' => 'applications/feed/story/base',
|
2012-02-27 18:49:01 +01:00
|
|
|
'PhabricatorFeedStoryAudit' => 'applications/feed/story/audit',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryData' => 'applications/feed/storage/story',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryDifferential' => 'applications/feed/story/differential',
|
2011-12-17 22:27:11 +01:00
|
|
|
'PhabricatorFeedStoryManiphest' => 'applications/feed/story/maniphest',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhabricatorFeedStoryPhriction' => 'applications/feed/story/phriction',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorFeedStoryProject' => 'applications/feed/story/project',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryPublisher' => 'applications/feed/publisher',
|
|
|
|
'PhabricatorFeedStoryReference' => 'applications/feed/storage/storyreference',
|
2011-07-09 22:28:09 +02:00
|
|
|
'PhabricatorFeedStoryStatus' => 'applications/feed/story/status',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryTypeConstants' => 'applications/feed/constants/story',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryUnknown' => 'applications/feed/story/unknown',
|
|
|
|
'PhabricatorFeedStoryView' => 'applications/feed/view/story',
|
|
|
|
'PhabricatorFeedView' => 'applications/feed/view/base',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFile' => 'applications/files/storage/file',
|
|
|
|
'PhabricatorFileController' => 'applications/files/controller/base',
|
|
|
|
'PhabricatorFileDAO' => 'applications/files/storage/base',
|
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' => 'applications/files/controller/data',
|
2012-01-16 22:26:44 +01:00
|
|
|
'PhabricatorFileDeleteController' => 'applications/files/controller/delete',
|
2011-05-22 20:55:10 +02:00
|
|
|
'PhabricatorFileDropUploadController' => 'applications/files/controller/dropupload',
|
2011-04-14 00:15:48 +02:00
|
|
|
'PhabricatorFileImageMacro' => 'applications/files/storage/imagemacro',
|
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' => 'applications/files/controller/info',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileListController' => 'applications/files/controller/list',
|
2011-05-03 19:45:45 +02:00
|
|
|
'PhabricatorFileMacroDeleteController' => 'applications/files/controller/macrodelete',
|
|
|
|
'PhabricatorFileMacroEditController' => 'applications/files/controller/macroedit',
|
|
|
|
'PhabricatorFileMacroListController' => 'applications/files/controller/macrolist',
|
2011-05-02 23:20:24 +02:00
|
|
|
'PhabricatorFileProxyController' => 'applications/files/controller/proxy',
|
|
|
|
'PhabricatorFileProxyImage' => 'applications/files/storage/proxyimage',
|
2011-12-15 07:37:23 +01:00
|
|
|
'PhabricatorFileSideNavView' => 'applications/files/view/sidenav',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileStorageBlob' => 'applications/files/storage/storageblob',
|
2012-04-09 00:07:34 +02:00
|
|
|
'PhabricatorFileStorageConfigurationException' => 'applications/files/exception/configuration',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorFileStorageEngine' => 'applications/files/engine/base',
|
|
|
|
'PhabricatorFileStorageEngineSelector' => 'applications/files/engineselector/base',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorFileTransformController' => 'applications/files/controller/transform',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileUploadController' => 'applications/files/controller/upload',
|
2011-08-16 21:37:50 +02:00
|
|
|
'PhabricatorFileUploadException' => 'applications/files/exception/upload',
|
2011-12-15 07:37:23 +01:00
|
|
|
'PhabricatorFileUploadView' => 'applications/files/view/upload',
|
2012-03-28 01:22:40 +02:00
|
|
|
'PhabricatorFlag' => 'applications/flag/storage/flag',
|
|
|
|
'PhabricatorFlagColor' => 'applications/flag/constants/color',
|
|
|
|
'PhabricatorFlagConstants' => 'applications/flag/constants/base',
|
|
|
|
'PhabricatorFlagController' => 'applications/flag/controller/base',
|
|
|
|
'PhabricatorFlagDAO' => 'applications/flag/storage/base',
|
|
|
|
'PhabricatorFlagDeleteController' => 'applications/flag/controller/delete',
|
|
|
|
'PhabricatorFlagEditController' => 'applications/flag/controller/edit',
|
|
|
|
'PhabricatorFlagListController' => 'applications/flag/controller/list',
|
|
|
|
'PhabricatorFlagListView' => 'applications/flag/view/list',
|
|
|
|
'PhabricatorFlagQuery' => 'applications/flag/query/flag',
|
2012-04-04 21:14:10 +02:00
|
|
|
'PhabricatorFormExample' => 'applications/uiexample/examples/form',
|
2011-07-03 18:47:31 +02:00
|
|
|
'PhabricatorGarbageCollectorDaemon' => 'infrastructure/daemon/garbagecollector',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorGoodForNothingWorker' => 'infrastructure/daemon/workers/worker/goodfornothing',
|
2011-02-17 23:32:01 +01:00
|
|
|
'PhabricatorHandleObjectSelectorDataView' => 'applications/phid/handle/view/selector',
|
2011-12-18 20:00:39 +01:00
|
|
|
'PhabricatorHash' => 'infrastructure/util/hash',
|
2011-05-28 20:36:00 +02:00
|
|
|
'PhabricatorHelpController' => 'applications/help/controller/base',
|
|
|
|
'PhabricatorHelpKeyboardShortcutController' => 'applications/help/controller/keyboardshortcut',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorIDPagedPolicyQuery' => 'infrastructure/query/policy/idpaged',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCBot' => 'infrastructure/daemon/irc/bot',
|
2012-01-06 20:31:00 +01:00
|
|
|
'PhabricatorIRCDifferentialNotificationHandler' => 'infrastructure/daemon/irc/handler/differentialnotification',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCHandler' => 'infrastructure/daemon/irc/handler/base',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorIRCLogHandler' => 'infrastructure/daemon/irc/handler/log',
|
2012-03-09 21:40:03 +01:00
|
|
|
'PhabricatorIRCMacroHandler' => 'infrastructure/daemon/irc/handler/macro',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCMessage' => 'infrastructure/daemon/irc/message',
|
2011-05-17 23:40:25 +02:00
|
|
|
'PhabricatorIRCObjectNameHandler' => 'infrastructure/daemon/irc/handler/objectname',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCProtocolHandler' => 'infrastructure/daemon/irc/handler/protocol',
|
2012-02-24 03:01:25 +01:00
|
|
|
'PhabricatorIRCWhatsNewHandler' => 'infrastructure/daemon/irc/handler/whatsnew',
|
2011-06-26 17:37:47 +02:00
|
|
|
'PhabricatorImageTransformer' => 'applications/files/transform',
|
2011-10-20 03:26:21 +02:00
|
|
|
'PhabricatorInfrastructureTestCase' => 'infrastructure/__tests__',
|
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' => 'infrastructure/diff/controller',
|
|
|
|
'PhabricatorInlineCommentInterface' => 'infrastructure/diff/interface/inline',
|
2012-03-20 03:45:16 +01:00
|
|
|
'PhabricatorInlineSummaryView' => 'infrastructure/diff/view/inline',
|
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' => 'infrastructure/lint/linter/javelin',
|
2012-03-06 04:51:16 +01:00
|
|
|
'PhabricatorJumpNavHandler' => 'applications/search/engine/jumpnav',
|
Bring Javelin into Phabricator via git submodule, not copy-and-paste
Summary:
Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt
packages. This is not so great.
Pull it in as a submodule instead and make all the Phabriator resources declare
proper dependency trees. Add Javelin linting.
Test Plan:
I tried to run through pretty much all the JS functionality on the site. This is
still a high-risk change, but I did a pretty thorough test
Differential: inline comments, revealing diffs, list tokenizers, comment
preview, editing/deleting comments, add review action.
Maniphest: list tokenizer, comment actions
Herald: rule editing, tokenizers, add/remove rows
Reviewed By: tomo
Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen
CC: aran, tomo, epriestley
Differential Revision: 223
2011-05-04 00:11:55 +02:00
|
|
|
'PhabricatorLintEngine' => 'infrastructure/lint/engine',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorLiskDAO' => 'applications/base/storage/lisk',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorLocalDiskFileStorageEngine' => 'applications/files/engine/localdisk',
|
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' => 'view/utils/__tests__',
|
2011-01-31 06:28:45 +01:00
|
|
|
'PhabricatorLoginController' => 'applications/auth/controller/login',
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
'PhabricatorLoginValidateController' => 'applications/auth/controller/validate',
|
2011-01-31 06:28:45 +01:00
|
|
|
'PhabricatorLogoutController' => 'applications/auth/controller/logout',
|
2011-01-26 18:33:31 +01:00
|
|
|
'PhabricatorMailImplementationAdapter' => 'applications/metamta/adapter/base',
|
2011-02-08 06:08:32 +01:00
|
|
|
'PhabricatorMailImplementationAmazonSESAdapter' => 'applications/metamta/adapter/amazonses',
|
2011-01-26 18:33:31 +01:00
|
|
|
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'applications/metamta/adapter/phpmailerlite',
|
2011-05-26 19:00:26 +02:00
|
|
|
'PhabricatorMailImplementationSendGridAdapter' => 'applications/metamta/adapter/sendgrid',
|
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' => 'applications/metamta/adapter/test',
|
2011-05-10 01:31:26 +02:00
|
|
|
'PhabricatorMailReplyHandler' => 'applications/metamta/replyhandler/base',
|
Generalize the markup engine factory
Summary:
This thing services every app but it lives inside Differential right now. Pull
it out, and separate the factory interfaces per-application.
This will let us accommodate changes we need to make for Phriction to support
wiki linking.
Test Plan: Tested remarkup in differential, diffusion, maniphest, people,
slowvote.
Reviewed By: hsb
Reviewers: hsb, codeblock, jungejason, tuomaspelkonen, aran
CC: aran, hsb
Differential Revision: 646
2011-07-12 00:58:32 +02:00
|
|
|
'PhabricatorMarkupEngine' => 'applications/markup/engine',
|
2011-11-09 00:15:44 +01:00
|
|
|
'PhabricatorMetaMTAAttachment' => 'applications/metamta/storage/mail',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAController' => 'applications/metamta/controller/base',
|
|
|
|
'PhabricatorMetaMTADAO' => 'applications/metamta/storage/base',
|
2011-06-01 17:33:14 +02:00
|
|
|
'PhabricatorMetaMTAEmailBodyParser' => 'applications/metamta/parser',
|
|
|
|
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'applications/metamta/parser/__tests__',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAListController' => 'applications/metamta/controller/list',
|
|
|
|
'PhabricatorMetaMTAMail' => 'applications/metamta/storage/mail',
|
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' => 'applications/metamta/storage/mail/__tests__',
|
2011-01-26 19:40:38 +01:00
|
|
|
'PhabricatorMetaMTAMailingList' => 'applications/metamta/storage/mailinglist',
|
|
|
|
'PhabricatorMetaMTAMailingListEditController' => 'applications/metamta/controller/mailinglistedit',
|
|
|
|
'PhabricatorMetaMTAMailingListsController' => 'applications/metamta/controller/mailinglists',
|
2011-05-05 08:09:42 +02:00
|
|
|
'PhabricatorMetaMTAReceiveController' => 'applications/metamta/controller/receive',
|
|
|
|
'PhabricatorMetaMTAReceivedListController' => 'applications/metamta/controller/receivedlist',
|
|
|
|
'PhabricatorMetaMTAReceivedMail' => 'applications/metamta/storage/receivedmail',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTASendController' => 'applications/metamta/controller/send',
|
2011-05-30 20:07:05 +02:00
|
|
|
'PhabricatorMetaMTASendGridReceiveController' => 'applications/metamta/controller/sendgridreceive',
|
2011-01-26 18:08:26 +01:00
|
|
|
'PhabricatorMetaMTAViewController' => 'applications/metamta/controller/view',
|
2012-02-28 02:11:25 +01:00
|
|
|
'PhabricatorMetaMTAWorker' => 'applications/metamta/worker',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorMySQLFileStorageEngine' => 'applications/files/engine/mysql',
|
2012-03-07 05:14:03 +01:00
|
|
|
'PhabricatorNotificationsController' => 'applications/notifications/controller/base',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthClientAuthorization' => 'applications/oauthserver/storage/clientauthorization',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientAuthorizationBaseController' => 'applications/oauthserver/controller/clientauthorization/base',
|
|
|
|
'PhabricatorOAuthClientAuthorizationDeleteController' => 'applications/oauthserver/controller/clientauthorization/delete',
|
|
|
|
'PhabricatorOAuthClientAuthorizationEditController' => 'applications/oauthserver/controller/clientauthorization/edit',
|
|
|
|
'PhabricatorOAuthClientAuthorizationListController' => 'applications/oauthserver/controller/clientauthorization/list',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthClientAuthorizationQuery' => 'applications/oauthserver/query/clientauthorization',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientBaseController' => 'applications/oauthserver/controller/client/base',
|
|
|
|
'PhabricatorOAuthClientDeleteController' => 'applications/oauthserver/controller/client/delete',
|
|
|
|
'PhabricatorOAuthClientEditController' => 'applications/oauthserver/controller/client/edit',
|
|
|
|
'PhabricatorOAuthClientListController' => 'applications/oauthserver/controller/client/list',
|
|
|
|
'PhabricatorOAuthClientViewController' => 'applications/oauthserver/controller/client/view',
|
2011-02-28 04:47:22 +01:00
|
|
|
'PhabricatorOAuthDefaultRegistrationController' => 'applications/auth/controller/oauthregistration/default',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorOAuthDiagnosticsController' => 'applications/auth/controller/oauthdiagnostics',
|
|
|
|
'PhabricatorOAuthFailureView' => 'applications/auth/view/oauthfailure',
|
|
|
|
'PhabricatorOAuthLoginController' => 'applications/auth/controller/oauth',
|
|
|
|
'PhabricatorOAuthProvider' => 'applications/auth/oauth/provider/base',
|
|
|
|
'PhabricatorOAuthProviderFacebook' => 'applications/auth/oauth/provider/facebook',
|
2012-02-03 02:25:31 +01:00
|
|
|
'PhabricatorOAuthProviderGitHub' => 'applications/auth/oauth/provider/github',
|
Add Google as an OAuth2 provider (BETA)
Summary:
This is pretty straightforward, except:
- We need to request read/write access to the address book to get the account
ID (which we MUST have) and real name, email and account name (which we'd like
to have). This is way more access than we should need, but there's apparently no
"get_loggedin_user_basic_information" type of call in the Google API suite (or,
at least, I couldn't find one).
- We can't get the profile picture or profile URI since there's no Plus API
access and Google users don't have meaningful public pages otherwise.
- Google doesn't save the fact that you've authorized the app, so every time
you want to login you need to reaffirm that you want to give us silly amounts of
access. Phabricator sessions are pretty long-duration though so this shouldn't
be a major issue.
Test Plan:
- Registered, logged out, and logged in with Google.
- Registered, logged out, and logged in with Facebook / Github to make sure I
didn't break anything.
- Linked / unlinked Google accounts.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, epriestley, Makinde
Differential Revision: 916
2011-09-09 01:37:22 +02:00
|
|
|
'PhabricatorOAuthProviderGoogle' => 'applications/auth/oauth/provider/google',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthProviderPhabricator' => 'applications/auth/oauth/provider/phabricator',
|
2011-02-28 04:47:22 +01:00
|
|
|
'PhabricatorOAuthRegistrationController' => 'applications/auth/controller/oauthregistration/base',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthResponse' => 'applications/oauthserver/response',
|
|
|
|
'PhabricatorOAuthServer' => 'applications/oauthserver/server',
|
|
|
|
'PhabricatorOAuthServerAccessToken' => 'applications/oauthserver/storage/accesstoken',
|
|
|
|
'PhabricatorOAuthServerAuthController' => 'applications/oauthserver/controller/auth',
|
|
|
|
'PhabricatorOAuthServerAuthorizationCode' => 'applications/oauthserver/storage/authorizationcode',
|
|
|
|
'PhabricatorOAuthServerClient' => 'applications/oauthserver/storage/client',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthServerClientQuery' => 'applications/oauthserver/query/client',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthServerController' => 'applications/oauthserver/controller/base',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthServerDAO' => 'applications/oauthserver/storage/base',
|
2012-02-21 23:28:05 +01:00
|
|
|
'PhabricatorOAuthServerScope' => 'applications/oauthserver/scope',
|
OAuthServer polish and random sauce
Summary:
This diff makes the OAuthServer more compliant with the spec by
- making it return well-formatted error codes with error types from the spec.
- making it respect the "state" variable, which is a transparent variable the
client passes and the server passes back
- making it be super, duper compliant with respect to redirect uris
-- if specified in authorization step, check if its valid relative to the client
registered URI and if so save it
-- if specified in authorization step, check if its been specified in the access
step and error if it doesn't match or doesn't exist
-- note we don't make any use of it in the access step which seems strange but
hey, that's what the spec says!
This diff makes the OAuthServer suck less by
- making the "cancel" button do something in the user authorization flow
- making the client list view and client edit view be a bit more usable around
client secrets
- fixing a few bugs I managed to introduce along the way
Test Plan:
- create a test phabricator client, updated my conf, and then linked and
unlinked phabricator to itself
- wrote some tests for PhabricatorOAuthServer -- they pass!
-- these validate the various validate URI checks
- tried a few important authorization calls
--
http://phabricator.dev/oauthserver/auth/?client_id=X&state=test&redirect_uri=http://www.evil.com
--- verified error'd from mismatching redirect uri's
--- verified state parameter in response
--- verified did not redirect to client redirect uri
-- http://phabricator.dev/oauthserver/auth/?client_id=X w/ existing
authorization
--- got redirected to proper client url with error that response_type not
specified
-- http://phabricator.dev/oauthserver/auth/?client_id=X&response_type=code w/
existing authorization
--- got redirected to proper client url with pertinent code!
- tried a few important access calls
-- verified appropriate errors if missing any required parameters
-- verified good access code with appropriate other variables resulted in an
access token
- verified that if redirect_uri set correctly in authorization required for
access and errors if differs at all / only succeeds if exactly the same
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley, ajtrichards
Maniphest Tasks: T889, T906, T897
Differential Revision: https://secure.phabricator.com/D1727
2012-03-01 23:46:18 +01:00
|
|
|
'PhabricatorOAuthServerTestCase' => 'applications/oauthserver/server/__tests__',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthServerTestController' => 'applications/oauthserver/controller/test',
|
|
|
|
'PhabricatorOAuthServerTokenController' => 'applications/oauthserver/controller/token',
|
2011-02-22 07:51:34 +01:00
|
|
|
'PhabricatorOAuthUnlinkController' => 'applications/auth/controller/unlink',
|
2011-12-16 23:45:10 +01:00
|
|
|
'PhabricatorObjectAttachmentEditor' => 'applications/search/editor/attach',
|
2011-07-05 22:18:47 +02:00
|
|
|
'PhabricatorObjectGraph' => 'applications/phid/graph',
|
2011-01-26 18:02:09 +01:00
|
|
|
'PhabricatorObjectHandle' => 'applications/phid/handle',
|
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
|
|
|
'PhabricatorObjectHandleConstants' => 'applications/phid/handle/const/base',
|
2011-01-26 18:02:09 +01:00
|
|
|
'PhabricatorObjectHandleData' => 'applications/phid/handle/data',
|
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' => 'applications/phid/handle/const/status',
|
2011-02-17 07:14:09 +01:00
|
|
|
'PhabricatorObjectSelectorDialog' => 'view/control/objectselector',
|
2012-03-27 05:54:26 +02:00
|
|
|
'PhabricatorOffsetPagedQuery' => 'infrastructure/query/offsetpaged',
|
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
|
|
|
'PhabricatorOwnerPathQuery' => 'applications/owners/query/path',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersController' => 'applications/owners/controller/base',
|
|
|
|
'PhabricatorOwnersDAO' => 'applications/owners/storage/base',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersDeleteController' => 'applications/owners/controller/delete',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersDetailController' => 'applications/owners/controller/detail',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersEditController' => 'applications/owners/controller/edit',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersListController' => 'applications/owners/controller/list',
|
|
|
|
'PhabricatorOwnersOwner' => 'applications/owners/storage/owner',
|
|
|
|
'PhabricatorOwnersPackage' => 'applications/owners/storage/package',
|
|
|
|
'PhabricatorOwnersPath' => 'applications/owners/storage/path',
|
2011-01-23 06:09:13 +01:00
|
|
|
'PhabricatorPHID' => 'applications/phid/storage/phid',
|
2011-03-03 03:58:21 +01:00
|
|
|
'PhabricatorPHIDConstants' => 'applications/phid/constants',
|
2011-01-23 06:09:13 +01:00
|
|
|
'PhabricatorPHIDController' => 'applications/phid/controller/base',
|
|
|
|
'PhabricatorPHIDDAO' => 'applications/phid/storage/base',
|
2011-01-26 18:02:09 +01:00
|
|
|
'PhabricatorPHIDLookupController' => 'applications/phid/controller/lookup',
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPaste' => 'applications/paste/storage/paste',
|
|
|
|
'PhabricatorPasteController' => 'applications/paste/controller/base',
|
|
|
|
'PhabricatorPasteDAO' => 'applications/paste/storage/base',
|
2011-06-14 04:12:30 +02:00
|
|
|
'PhabricatorPasteListController' => 'applications/paste/controller/list',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorPasteQuery' => 'applications/paste/query/paste',
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPasteViewController' => 'applications/paste/controller/view',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleController' => 'applications/people/controller/base',
|
|
|
|
'PhabricatorPeopleEditController' => 'applications/people/controller/edit',
|
|
|
|
'PhabricatorPeopleListController' => 'applications/people/controller/list',
|
Provide an activity log for login and administrative actions
Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish.
Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen:
- The log itself is useful if there are shenanigans.
- Password login can check it and start CAPTCHA'ing users after a few failed attempts.
I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow.
Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways.
Reviewers: jungejason, tuomaspelkonen, aran
CC:
Differential Revision: 302
2011-05-18 03:42:21 +02:00
|
|
|
'PhabricatorPeopleLogsController' => 'applications/people/controller/logs',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleProfileController' => 'applications/people/controller/profile',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorPolicies' => 'applications/policy/constants/policy',
|
|
|
|
'PhabricatorPolicyCapability' => 'applications/policy/constants/capability',
|
|
|
|
'PhabricatorPolicyConstants' => 'applications/policy/constants/base',
|
|
|
|
'PhabricatorPolicyException' => 'applications/policy/exception/base',
|
|
|
|
'PhabricatorPolicyFilter' => 'applications/policy/filter/policy',
|
|
|
|
'PhabricatorPolicyInterface' => 'applications/policy/interface/policy',
|
|
|
|
'PhabricatorPolicyQuery' => 'infrastructure/query/policy/base',
|
|
|
|
'PhabricatorPolicyTestCase' => 'applications/policy/__tests__',
|
|
|
|
'PhabricatorPolicyTestObject' => 'applications/policy/__tests__',
|
|
|
|
'PhabricatorPolicyTestQuery' => 'applications/policy/__tests__',
|
2011-12-17 05:01:38 +01:00
|
|
|
'PhabricatorProfileHeaderView' => 'view/layout/profileheader',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProject' => 'applications/project/storage/project',
|
|
|
|
'PhabricatorProjectAffiliation' => 'applications/project/storage/affiliation',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorProjectConstants' => 'applications/project/constants/base',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectController' => 'applications/project/controller/base',
|
2011-06-26 17:37:47 +02:00
|
|
|
'PhabricatorProjectCreateController' => 'applications/project/controller/create',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectDAO' => 'applications/project/storage/base',
|
Provide wiki pages for projects
Summary:
Provide tighter integration between Projects and Phriction. Partly, I have most
of a rewrite for the Projects homepage ready but it's not currently possible to
publish feed stories about a project so all the feeds are empty/boring. This
partly makes them more useful and partly just provides a tool integration point.
- When you create a project, all the wiki pages in projects/<project_name>/*
are associated with it.
- Publish updates to those pages as being related to the project so they'll
show up in project feeds.
- Show a project link on those pages.
This is very "convention over configuration" but I think it's the right
approach. We could provide some sort of, like, "@project=derp" tag to let you
associated arbitrary pages to projects later, but just letting you move pages is
probably far better.
Test Plan:
- Ran upgrade scripts against stupidly named projects ("der", " der", " der
", "der (2)", " der (2) (2)", etc). Ended up with uniquely named projects.
- Ran unit tests.
- Created /projects/ wiki documents and made sure they displayed correctly.
- Verified feed stories publish as project-related.
- Edited projects, including perfomring a name-colliding edit.
- Created projects, including performing a name-colliding create.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, btrahan
Maniphest Tasks: T681
Differential Revision: 1231
2011-12-17 20:58:55 +01:00
|
|
|
'PhabricatorProjectEditor' => 'applications/project/editor/project',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectListController' => 'applications/project/controller/list',
|
Provide wiki pages for projects
Summary:
Provide tighter integration between Projects and Phriction. Partly, I have most
of a rewrite for the Projects homepage ready but it's not currently possible to
publish feed stories about a project so all the feeds are empty/boring. This
partly makes them more useful and partly just provides a tool integration point.
- When you create a project, all the wiki pages in projects/<project_name>/*
are associated with it.
- Publish updates to those pages as being related to the project so they'll
show up in project feeds.
- Show a project link on those pages.
This is very "convention over configuration" but I think it's the right
approach. We could provide some sort of, like, "@project=derp" tag to let you
associated arbitrary pages to projects later, but just letting you move pages is
probably far better.
Test Plan:
- Ran upgrade scripts against stupidly named projects ("der", " der", " der
", "der (2)", " der (2) (2)", etc). Ended up with uniquely named projects.
- Ran unit tests.
- Created /projects/ wiki documents and made sure they displayed correctly.
- Verified feed stories publish as project-related.
- Edited projects, including perfomring a name-colliding edit.
- Created projects, including performing a name-colliding create.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, btrahan
Maniphest Tasks: T681
Differential Revision: 1231
2011-12-17 20:58:55 +01:00
|
|
|
'PhabricatorProjectNameCollisionException' => 'applications/project/exception/namecollison',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectProfile' => 'applications/project/storage/profile',
|
|
|
|
'PhabricatorProjectProfileController' => 'applications/project/controller/profile',
|
2011-06-18 10:13:56 +02:00
|
|
|
'PhabricatorProjectProfileEditController' => 'applications/project/controller/profileedit',
|
2011-12-17 02:08:18 +01:00
|
|
|
'PhabricatorProjectQuery' => 'applications/project/query/project',
|
2011-06-18 10:13:56 +02:00
|
|
|
'PhabricatorProjectStatus' => 'applications/project/constants/status',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorProjectSubproject' => 'applications/project/storage/subproject',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorProjectTransaction' => 'applications/project/storage/transaction',
|
|
|
|
'PhabricatorProjectTransactionType' => 'applications/project/constants/transaction',
|
2012-01-25 20:51:20 +01:00
|
|
|
'PhabricatorProjectUpdateController' => 'applications/project/controller/update',
|
2012-03-27 05:54:26 +02:00
|
|
|
'PhabricatorQuery' => 'infrastructure/query/base',
|
2011-04-04 19:29:46 +02:00
|
|
|
'PhabricatorRedirectController' => 'applications/base/controller/redirect',
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
'PhabricatorRefreshCSRFController' => 'applications/auth/controller/refresh',
|
2011-02-12 03:06:43 +01:00
|
|
|
'PhabricatorRemarkupRuleDifferential' => 'infrastructure/markup/remarkup/markuprule/differential',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleDifferentialHandle' => 'infrastructure/markup/remarkup/markuprule/handle/differential',
|
2011-04-11 12:02:19 +02:00
|
|
|
'PhabricatorRemarkupRuleDiffusion' => 'infrastructure/markup/remarkup/markuprule/diffusion',
|
2011-07-15 23:17:55 +02:00
|
|
|
'PhabricatorRemarkupRuleEmbedFile' => 'infrastructure/markup/remarkup/markuprule/embedobject',
|
2011-04-14 00:15:48 +02:00
|
|
|
'PhabricatorRemarkupRuleImageMacro' => 'infrastructure/markup/remarkup/markuprule/imagemacro',
|
2011-02-12 03:06:43 +01:00
|
|
|
'PhabricatorRemarkupRuleManiphest' => 'infrastructure/markup/remarkup/markuprule/maniphest',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleManiphestHandle' => 'infrastructure/markup/remarkup/markuprule/handle/maniphest',
|
2011-06-24 19:59:57 +02:00
|
|
|
'PhabricatorRemarkupRuleMention' => 'infrastructure/markup/remarkup/markuprule/mention',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleObjectHandle' => 'infrastructure/markup/remarkup/markuprule/handle',
|
2011-05-31 19:23:31 +02:00
|
|
|
'PhabricatorRemarkupRuleObjectName' => 'infrastructure/markup/remarkup/markuprule/objectname',
|
2011-06-27 08:57:43 +02:00
|
|
|
'PhabricatorRemarkupRulePaste' => 'infrastructure/markup/remarkup/markuprule/paste',
|
2011-07-12 05:14:46 +02:00
|
|
|
'PhabricatorRemarkupRulePhriction' => 'infrastructure/markup/remarkup/markuprule/phriction',
|
2011-05-02 23:20:24 +02:00
|
|
|
'PhabricatorRemarkupRuleProxyImage' => 'infrastructure/markup/remarkup/markuprule/proxyimage',
|
2011-05-27 21:50:02 +02:00
|
|
|
'PhabricatorRemarkupRuleYoutube' => 'infrastructure/markup/remarkup/markuprule/youtube',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepository' => 'applications/repository/storage/repository',
|
2011-04-06 05:49:31 +02:00
|
|
|
'PhabricatorRepositoryArcanistProject' => 'applications/repository/storage/arcanistproject',
|
|
|
|
'PhabricatorRepositoryArcanistProjectEditController' => 'applications/repository/controller/arcansistprojectedit',
|
Migrate "PhabricatorOwnersPackageCommitRelationship" to "PhabricatorRepositoryAuditRequest"
Summary:
- Move table to Repository, since we have no Owners joins in the application anymore but would like to do a Repository join.
- Rename "packagePHID" to "auditorPHID", since this column may contain package, project, or user PHIDs.
Test Plan:
- Browsed Owners, Audit, and Differential interfaces to the Audit tool.
- Made comments and state changes.
- Ran "reparse.php --herald --owners" on several commits.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, nh, vrana
Maniphest Tasks: T904
Differential Revision: https://secure.phabricator.com/D1787
2012-03-05 22:17:29 +01:00
|
|
|
'PhabricatorRepositoryAuditRequest' => 'applications/repository/storage/auditrequest',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryCommit' => 'applications/repository/storage/commit',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/base',
|
|
|
|
'PhabricatorRepositoryCommitData' => 'applications/repository/storage/commitdata',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/base',
|
2011-04-04 08:23:36 +02:00
|
|
|
'PhabricatorRepositoryCommitHeraldWorker' => 'applications/repository/worker/herald',
|
2011-04-02 02:11:05 +02:00
|
|
|
'PhabricatorRepositoryCommitMessageDetailParser' => 'applications/repository/parser/base',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/base',
|
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' => 'applications/repository/worker/owner',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitParserWorker' => 'applications/repository/worker/base',
|
|
|
|
'PhabricatorRepositoryCommitTaskDaemon' => 'applications/repository/daemon/committask',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryController' => 'applications/repository/controller/base',
|
|
|
|
'PhabricatorRepositoryCreateController' => 'applications/repository/controller/create',
|
|
|
|
'PhabricatorRepositoryDAO' => 'applications/repository/storage/base',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryDaemon' => 'applications/repository/daemon/base',
|
2011-04-02 02:11:05 +02:00
|
|
|
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'applications/repository/parser/default',
|
2011-05-05 21:53:39 +02:00
|
|
|
'PhabricatorRepositoryDeleteController' => 'applications/repository/controller/delete',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryEditController' => 'applications/repository/controller/edit',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/git',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/git',
|
2011-12-23 17:11:11 +01:00
|
|
|
'PhabricatorRepositoryGitCommitDiscoveryDaemonTestCase' => 'applications/repository/daemon/commitdiscovery/git/__tests__',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/git',
|
2011-03-21 01:46:02 +01:00
|
|
|
'PhabricatorRepositoryGitFetchDaemon' => 'applications/repository/daemon/gitfetch',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryListController' => 'applications/repository/controller/list',
|
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' => 'applications/repository/worker/commitchangeparser/mercurial',
|
Add a Mercurial commit discovery daemon
Summary:
Repository import has three major steps:
- Commit discovery (serial)
- Message parsing (parallel, mostly VCS independent)
- Change parsing (parallel, highly VCS dependent)
This implements commit discovery for Mercurial, similar to git's parsing:
- List the heads of all the branches.
- If we haven't already discovered them, follow them back to their roots (or
the first commit we have discovered).
- Import all the newly discovered commits, oldest first.
This is a little complicated but it ensures we discover commits in depth order,
so the discovery process is robust against interruption/failure. If we just
inserted commits as we went, we might read the tip, insert it, and then crash.
When we ran again, we'd think we had already discovered commits older than HEAD.
This also allows later stages to rely on being able to find Phabricator commit
IDs which correspond to parent commits.
NOTE: This importer is fairly slow because "hg" has a large startup time
(compare "hg --version" to "git --version" and "svn --version"; on my machine,
hg has 60ms of overhead for any command) and we need to run many commands (see
the whole "hg id" mess). You can expect something like 10,000 per hour, which
means you may need to run overnight to discover a large repository (IIRC, the
svn/git discovery processes are both about an order of magnitude faster). We
could improve this with batching, but I want to keep it as simple as possible
for now.
Test Plan: Discovered all the commits in the main Mercurial repository,
http://selenic.com/repo/hg.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde
Differential Revision: 943
2011-09-16 12:56:23 +02:00
|
|
|
'PhabricatorRepositoryMercurialCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/mercurial',
|
2011-09-16 18:37:15 +02:00
|
|
|
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/mercurial',
|
2011-08-09 21:47:46 +02:00
|
|
|
'PhabricatorRepositoryMercurialPullDaemon' => 'applications/repository/daemon/mercurialpull',
|
|
|
|
'PhabricatorRepositoryPullLocalDaemon' => 'applications/repository/daemon/pulllocal',
|
2011-03-31 09:33:44 +02:00
|
|
|
'PhabricatorRepositoryShortcut' => 'applications/repository/storage/shortcut',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'applications/repository/worker/commitchangeparser/svn',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositorySvnCommitDiscoveryDaemon' => 'applications/repository/daemon/commitdiscovery/svn',
|
|
|
|
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'applications/repository/worker/commitmessageparser/svn',
|
2011-09-05 02:31:16 +02:00
|
|
|
'PhabricatorRepositorySymbol' => 'applications/repository/storage/symbol',
|
2011-12-23 17:11:11 +01:00
|
|
|
'PhabricatorRepositoryTestCase' => 'applications/repository/storage/repository/__tests__',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryType' => 'applications/repository/constants/repositorytype',
|
2011-07-31 22:54:58 +02:00
|
|
|
'PhabricatorS3FileStorageEngine' => 'applications/files/engine/s3',
|
2011-05-05 20:00:05 +02:00
|
|
|
'PhabricatorSQLPatchList' => 'infrastructure/setup/sql',
|
2012-04-17 16:52:01 +02:00
|
|
|
'PhabricatorScopedEnv' => 'infrastructure/env',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchAbstractDocument' => 'applications/search/index/abstractdocument',
|
2011-05-16 20:43:39 +02:00
|
|
|
'PhabricatorSearchAttachController' => 'applications/search/controller/attach',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchBaseController' => 'applications/search/controller/base',
|
2011-06-20 06:02:48 +02:00
|
|
|
'PhabricatorSearchCommitIndexer' => 'applications/search/index/indexer/repository',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchController' => 'applications/search/controller/search',
|
|
|
|
'PhabricatorSearchDAO' => 'applications/search/storage/base',
|
|
|
|
'PhabricatorSearchDifferentialIndexer' => 'applications/search/index/indexer/differential',
|
|
|
|
'PhabricatorSearchDocument' => 'applications/search/storage/document/document',
|
|
|
|
'PhabricatorSearchDocumentField' => 'applications/search/storage/document/field',
|
|
|
|
'PhabricatorSearchDocumentIndexer' => 'applications/search/index/indexer/base',
|
|
|
|
'PhabricatorSearchDocumentRelationship' => 'applications/search/storage/document/relationship',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorSearchEngine' => 'applications/search/engine/base',
|
[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' => 'applications/search/engine/elastic',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorSearchEngineMySQL' => 'applications/search/engine/mysql',
|
|
|
|
'PhabricatorSearchEngineSelector' => 'applications/search/selector/base',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchField' => 'applications/search/constants/field',
|
2011-06-15 16:43:43 +02:00
|
|
|
'PhabricatorSearchIndexController' => 'applications/search/controller/index',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchManiphestIndexer' => 'applications/search/index/indexer/maniphest',
|
2011-07-12 02:29:08 +02:00
|
|
|
'PhabricatorSearchPhrictionIndexer' => 'applications/search/index/indexer/phriction',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchQuery' => 'applications/search/storage/query',
|
|
|
|
'PhabricatorSearchRelationship' => 'applications/search/constants/relationship',
|
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' => 'applications/search/view/searchresult',
|
2012-02-15 02:00:12 +01:00
|
|
|
'PhabricatorSearchScope' => 'applications/search/constants/scope',
|
2011-05-16 20:43:39 +02:00
|
|
|
'PhabricatorSearchSelectController' => 'applications/search/controller/select',
|
2011-06-23 22:31:20 +02:00
|
|
|
'PhabricatorSearchUserIndexer' => 'applications/search/index/indexer/user',
|
2011-05-05 20:00:05 +02:00
|
|
|
'PhabricatorSetup' => 'infrastructure/setup',
|
2011-07-08 20:13:11 +02:00
|
|
|
'PhabricatorSlowvoteChoice' => 'applications/slowvote/storage/choice',
|
|
|
|
'PhabricatorSlowvoteComment' => 'applications/slowvote/storage/comment',
|
|
|
|
'PhabricatorSlowvoteController' => 'applications/slowvote/controller/base',
|
|
|
|
'PhabricatorSlowvoteCreateController' => 'applications/slowvote/controller/create',
|
|
|
|
'PhabricatorSlowvoteDAO' => 'applications/slowvote/storage/base',
|
|
|
|
'PhabricatorSlowvoteListController' => 'applications/slowvote/controller/list',
|
|
|
|
'PhabricatorSlowvoteOption' => 'applications/slowvote/storage/option',
|
|
|
|
'PhabricatorSlowvotePoll' => 'applications/slowvote/storage/poll',
|
|
|
|
'PhabricatorSlowvotePollController' => 'applications/slowvote/controller/poll',
|
2012-04-10 23:18:20 +02:00
|
|
|
'PhabricatorSlug' => 'infrastructure/util/slug',
|
|
|
|
'PhabricatorSlugTestCase' => 'infrastructure/util/slug/__tests__',
|
2012-03-20 03:48:22 +01:00
|
|
|
'PhabricatorSortTableExample' => 'applications/uiexample/examples/sorttable',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorStandardPageView' => 'view/page/standard',
|
2011-04-08 20:13:29 +02:00
|
|
|
'PhabricatorStatusController' => 'applications/status/base',
|
2011-08-30 22:12:20 +02:00
|
|
|
'PhabricatorSymbolNameLinter' => 'infrastructure/lint/hook/xhpastsymbolname',
|
2011-07-06 21:12:17 +02:00
|
|
|
'PhabricatorSyntaxHighlighter' => 'applications/markup/syntax',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorTaskmasterDaemon' => 'infrastructure/daemon/workers/taskmaster',
|
2011-04-30 19:11:41 +02:00
|
|
|
'PhabricatorTestCase' => 'infrastructure/testing/testcase',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorTimelineCursor' => 'infrastructure/daemon/timeline/storage/cursor',
|
|
|
|
'PhabricatorTimelineDAO' => 'infrastructure/daemon/timeline/storage/base',
|
|
|
|
'PhabricatorTimelineEvent' => 'infrastructure/daemon/timeline/storage/event',
|
|
|
|
'PhabricatorTimelineEventData' => 'infrastructure/daemon/timeline/storage/eventdata',
|
|
|
|
'PhabricatorTimelineIterator' => 'infrastructure/daemon/timeline/cursor/iterator',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorTimer' => 'applications/countdown/storage/timer',
|
2012-02-24 22:02:35 +01:00
|
|
|
'PhabricatorTransactionView' => 'view/layout/transaction',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorTransformedFile' => 'applications/files/storage/transformed',
|
2011-08-03 17:17:53 +02:00
|
|
|
'PhabricatorTrivialTestCase' => 'infrastructure/testing/testcase/__tests__',
|
2011-01-25 22:48:05 +01:00
|
|
|
'PhabricatorTypeaheadCommonDatasourceController' => 'applications/typeahead/controller/common',
|
|
|
|
'PhabricatorTypeaheadDatasourceController' => 'applications/typeahead/controller/base',
|
2011-04-01 02:06:33 +02:00
|
|
|
'PhabricatorUIExample' => 'applications/uiexample/examples/base',
|
|
|
|
'PhabricatorUIExampleController' => 'applications/uiexample/controller/base',
|
|
|
|
'PhabricatorUIExampleRenderController' => 'applications/uiexample/controller/render',
|
2011-04-04 00:50:06 +02:00
|
|
|
'PhabricatorUIListFilterExample' => 'applications/uiexample/examples/listfilter',
|
2011-04-01 02:06:33 +02:00
|
|
|
'PhabricatorUIPagerExample' => 'applications/uiexample/examples/pager',
|
2012-03-13 02:21:02 +01:00
|
|
|
'PhabricatorUITooltipExample' => 'applications/uiexample/examples/tooltip',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorUser' => 'applications/people/storage/user',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserAccountSettingsPanelController' => 'applications/people/controller/settings/panels/account',
|
|
|
|
'PhabricatorUserConduitSettingsPanelController' => 'applications/people/controller/settings/panels/conduit',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorUserDAO' => 'applications/people/storage/base',
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-18 05:32:28 +01:00
|
|
|
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/emailpref',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserEmailSettingsPanelController' => 'applications/people/controller/settings/panels/email',
|
Provide an activity log for login and administrative actions
Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish.
Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen:
- The log itself is useful if there are shenanigans.
- Password login can check it and start CAPTCHA'ing users after a few failed attempts.
I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow.
Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways.
Reviewers: jungejason, tuomaspelkonen, aran
CC:
Differential Revision: 302
2011-05-18 03:42:21 +02:00
|
|
|
'PhabricatorUserLog' => 'applications/people/storage/log',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorUserOAuthInfo' => 'applications/people/storage/useroauthinfo',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserOAuthSettingsPanelController' => 'applications/people/controller/settings/panels/oauth',
|
Add change password settings panel
Summary:
In password-based auth environments, there is now a user settings
panel to allow them to change their password.
Test Plan:
Click settings, choose password from the left:
* enter current password, new password (twice), log out, and log in with
new password
* enter current password, non-matching passwords, and get error
* enter invalid old password, and get error
* use firebug to change csrf token and verify that it does not save with
and invalid token
Changed config to disable password auth, loaded settings panel and saw
that password was no longer visible. Tried loading the panel anyway and
got redirected.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley
Differential Revision: 890
2011-09-04 10:53:58 +02:00
|
|
|
'PhabricatorUserPasswordSettingsPanelController' => 'applications/people/controller/settings/panels/password',
|
2011-07-24 20:02:08 +02:00
|
|
|
'PhabricatorUserPreferenceSettingsPanelController' => 'applications/people/controller/settings/panels/preferences',
|
2011-03-31 04:21:09 +02:00
|
|
|
'PhabricatorUserPreferences' => 'applications/people/storage/preferences',
|
2011-02-20 03:28:41 +01:00
|
|
|
'PhabricatorUserProfile' => 'applications/people/storage/profile',
|
2011-07-25 00:03:59 +02:00
|
|
|
'PhabricatorUserProfileSettingsPanelController' => 'applications/people/controller/settings/panels/profile',
|
2011-07-22 19:17:57 +02:00
|
|
|
'PhabricatorUserSSHKey' => 'applications/people/storage/usersshkey',
|
|
|
|
'PhabricatorUserSSHKeysSettingsPanelController' => 'applications/people/controller/settings/panels/sshkeys',
|
2012-03-15 04:47:17 +01:00
|
|
|
'PhabricatorUserSearchSettingsPanelController' => 'applications/people/controller/settings/panels/search',
|
2011-02-06 07:36:21 +01:00
|
|
|
'PhabricatorUserSettingsController' => 'applications/people/controller/settings',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserSettingsPanelController' => 'applications/people/controller/settings/panels/base',
|
2012-01-16 16:30:28 +01:00
|
|
|
'PhabricatorUserTestCase' => 'applications/people/storage/user/__tests__',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorWorker' => 'infrastructure/daemon/workers/worker',
|
|
|
|
'PhabricatorWorkerDAO' => 'infrastructure/daemon/workers/storage/base',
|
|
|
|
'PhabricatorWorkerTask' => 'infrastructure/daemon/workers/storage/task',
|
|
|
|
'PhabricatorWorkerTaskData' => 'infrastructure/daemon/workers/storage/taskdata',
|
2011-03-27 07:55:18 +02:00
|
|
|
'PhabricatorWorkerTaskDetailController' => 'applications/daemon/controller/workertaskdetail',
|
2012-01-24 01:36:32 +01:00
|
|
|
'PhabricatorWorkerTaskUpdateController' => 'applications/daemon/controller/workertaskupdate',
|
2011-04-07 04:17:05 +02:00
|
|
|
'PhabricatorXHPASTViewController' => 'applications/xhpastview/controller/base',
|
|
|
|
'PhabricatorXHPASTViewDAO' => 'applications/xhpastview/storage/base',
|
|
|
|
'PhabricatorXHPASTViewFrameController' => 'applications/xhpastview/controller/viewframe',
|
|
|
|
'PhabricatorXHPASTViewFramesetController' => 'applications/xhpastview/controller/viewframeset',
|
|
|
|
'PhabricatorXHPASTViewInputController' => 'applications/xhpastview/controller/viewinput',
|
|
|
|
'PhabricatorXHPASTViewPanelController' => 'applications/xhpastview/controller/viewpanel',
|
|
|
|
'PhabricatorXHPASTViewParseTree' => 'applications/xhpastview/storage/parsetree',
|
|
|
|
'PhabricatorXHPASTViewRunController' => 'applications/xhpastview/controller/run',
|
|
|
|
'PhabricatorXHPASTViewStreamController' => 'applications/xhpastview/controller/viewstream',
|
|
|
|
'PhabricatorXHPASTViewTreeController' => 'applications/xhpastview/controller/viewtree',
|
2011-02-02 22:48:52 +01:00
|
|
|
'PhabricatorXHProfController' => 'applications/xhprof/controller/base',
|
|
|
|
'PhabricatorXHProfProfileController' => 'applications/xhprof/controller/profile',
|
|
|
|
'PhabricatorXHProfProfileSymbolView' => 'applications/xhprof/view/symbol',
|
|
|
|
'PhabricatorXHProfProfileTopLevelView' => 'applications/xhprof/view/toplevel',
|
2012-01-28 20:17:19 +01:00
|
|
|
'PhabricatorXHProfProfileView' => 'applications/xhprof/view/base',
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhameController' => 'applications/phame/controller/base',
|
|
|
|
'PhameDAO' => 'applications/phame/storage/base',
|
|
|
|
'PhameDraftListController' => 'applications/phame/controller/post/list/drafts',
|
|
|
|
'PhamePost' => 'applications/phame/storage/post',
|
|
|
|
'PhamePostDeleteController' => 'applications/phame/controller/post/delete',
|
|
|
|
'PhamePostDetailView' => 'applications/phame/view/postdetail',
|
|
|
|
'PhamePostEditController' => 'applications/phame/controller/post/edit',
|
|
|
|
'PhamePostListBaseController' => 'applications/phame/controller/post/list/base',
|
|
|
|
'PhamePostListController' => 'applications/phame/controller/post/list/posts',
|
|
|
|
'PhamePostListView' => 'applications/phame/view/postlist',
|
|
|
|
'PhamePostPreviewController' => 'applications/phame/controller/post/preview',
|
|
|
|
'PhamePostQuery' => 'applications/phame/query/post',
|
|
|
|
'PhamePostViewController' => 'applications/phame/controller/post/view',
|
2012-04-05 01:09:29 +02:00
|
|
|
'PhortuneMonthYearExpiryControl' => 'applications/phortune/control/monthyearexpiry',
|
|
|
|
'PhortuneStripeBaseController' => 'applications/phortune/stripe/controller/base',
|
|
|
|
'PhortuneStripePaymentFormView' => 'applications/phortune/stripe/view/paymentform',
|
|
|
|
'PhortuneStripeTestPaymentFormController' => 'applications/phortune/stripe/controller/testpaymentform',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhrictionActionConstants' => 'applications/phriction/constants/action',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionChangeType' => 'applications/phriction/constants/changetype',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhrictionConstants' => 'applications/phriction/constants/base',
|
2011-07-11 21:34:53 +02:00
|
|
|
'PhrictionContent' => 'applications/phriction/storage/content',
|
2011-07-11 17:54:22 +02:00
|
|
|
'PhrictionController' => 'applications/phriction/controller/base',
|
|
|
|
'PhrictionDAO' => 'applications/phriction/storage/base',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionDeleteController' => 'applications/phriction/controller/delete',
|
2011-07-17 20:06:02 +02:00
|
|
|
'PhrictionDiffController' => 'applications/phriction/controller/diff',
|
2011-07-11 17:54:22 +02:00
|
|
|
'PhrictionDocument' => 'applications/phriction/storage/document',
|
|
|
|
'PhrictionDocumentController' => 'applications/phriction/controller/document',
|
2011-08-26 21:50:28 +02:00
|
|
|
'PhrictionDocumentEditor' => 'applications/phriction/editor/document',
|
2011-07-17 03:25:45 +02:00
|
|
|
'PhrictionDocumentPreviewController' => 'applications/phriction/controller/documentpreview',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionDocumentStatus' => 'applications/phriction/constants/documentstatus',
|
2011-07-12 17:08:03 +02:00
|
|
|
'PhrictionDocumentTestCase' => 'applications/phriction/storage/document/__tests__',
|
2011-07-11 21:34:53 +02:00
|
|
|
'PhrictionEditController' => 'applications/phriction/controller/edit',
|
2011-07-12 00:06:19 +02:00
|
|
|
'PhrictionHistoryController' => 'applications/phriction/controller/history',
|
2011-07-12 00:42:12 +02:00
|
|
|
'PhrictionListController' => 'applications/phriction/controller/list',
|
2011-12-14 02:34:41 +01:00
|
|
|
'QueryFormattingTestCase' => 'storage/qsprintf/__tests__',
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
|
|
|
'function' =>
|
|
|
|
array(
|
2012-04-02 23:45:07 +02:00
|
|
|
'_phabricator_date_format' => 'view/utils',
|
2011-01-16 22:51:39 +01:00
|
|
|
'_qsprintf_check_scalar_type' => 'storage/qsprintf',
|
|
|
|
'_qsprintf_check_type' => 'storage/qsprintf',
|
2011-01-31 20:55:26 +01:00
|
|
|
'celerity_generate_unique_node_id' => 'infrastructure/celerity/api',
|
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
|
|
|
'celerity_get_resource_uri' => 'infrastructure/celerity/api',
|
2011-01-31 20:55:26 +01:00
|
|
|
'celerity_register_resource_map' => 'infrastructure/celerity/map',
|
|
|
|
'javelin_render_tag' => 'infrastructure/javelin/markup',
|
2011-06-18 22:07:02 +02:00
|
|
|
'phabricator_date' => 'view/utils',
|
|
|
|
'phabricator_datetime' => 'view/utils',
|
2012-04-02 23:45:07 +02:00
|
|
|
'phabricator_format_local_time' => 'view/utils',
|
2011-01-31 03:24:57 +01:00
|
|
|
'phabricator_format_relative_time' => 'view/utils',
|
|
|
|
'phabricator_format_units_generic' => 'view/utils',
|
2012-03-31 00:46:32 +02:00
|
|
|
'phabricator_on_relative_date' => 'view/utils',
|
|
|
|
'phabricator_relative_date' => 'view/utils',
|
2011-02-15 00:34:20 +01:00
|
|
|
'phabricator_render_form' => 'infrastructure/javelin/markup',
|
2011-06-18 22:07:02 +02:00
|
|
|
'phabricator_time' => 'view/utils',
|
2012-03-31 00:46:32 +02:00
|
|
|
'phid_get_type' => 'applications/phid/utils',
|
|
|
|
'phid_group_by_type' => 'applications/phid/utils',
|
2011-01-16 22:51:39 +01:00
|
|
|
'qsprintf' => 'storage/qsprintf',
|
|
|
|
'queryfx' => 'storage/queryfx',
|
|
|
|
'queryfx_all' => 'storage/queryfx',
|
|
|
|
'queryfx_one' => 'storage/queryfx',
|
2011-01-31 20:55:26 +01:00
|
|
|
'require_celerity_resource' => 'infrastructure/celerity/api',
|
2011-01-16 22:51:39 +01:00
|
|
|
'vqsprintf' => 'storage/qsprintf',
|
|
|
|
'vqueryfx' => 'storage/queryfx',
|
2011-01-27 20:35:04 +01:00
|
|
|
'vqueryfx_all' => 'storage/queryfx',
|
2011-01-16 22:51:39 +01:00
|
|
|
'xsprintf_query' => 'storage/qsprintf',
|
|
|
|
),
|
|
|
|
'requires_class' =>
|
|
|
|
array(
|
2011-05-09 10:10:40 +02:00
|
|
|
'Aphront304Response' => 'AphrontResponse',
|
2011-01-30 21:08:40 +01:00
|
|
|
'Aphront400Response' => 'AphrontResponse',
|
2012-01-15 10:07:56 +01:00
|
|
|
'Aphront403Response' => 'AphrontWebpageResponse',
|
|
|
|
'Aphront404Response' => 'AphrontWebpageResponse',
|
2011-01-25 20:57:47 +01:00
|
|
|
'AphrontAjaxResponse' => 'AphrontResponse',
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
'AphrontAttachedFileView' => 'AphrontView',
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
'AphrontCSRFException' => 'AphrontException',
|
Build a basic calendar view
Summary:
This is a very small step toward building a Status and possibly an Oncall tool.
Build a calendar view which renders months.
Much of my hesitance to bang these tools out is that dealing with
dates/calendaring is basically horrible, so I'm trying to ease into it.
This calendar is locale-aware and all that jazz.
Test Plan:
- See:
https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/
- Verified that months have the right number of days, today is the right day
of the week, months begin on the day after previous months end on, etc.
Reviewed By: aran
Reviewers: jungejason, tuomaspelkonen, aran
Commenters: cwbeck, jungejason
CC: blair, aran, epriestley, cwbeck, jungejason
Differential Revision: 791
2011-08-08 03:26:31 +02:00
|
|
|
'AphrontCalendarMonthView' => 'AphrontView',
|
Tweak style on "Create Another Task" button
Summary:
Not totally sure I'm in love with this but I think it's somewhat non-terrible,
despite the lack of lens flare.
Also made "Cancel" take you back to the task if you got to "Create" from "Create
Another Task".
Test Plan:
- Style:
https://secure.phabricator.com/file/view/PHID-FILE-ad37d3c1f3b2c7a7a7d1/
- Hit "Cancel" from "Create Another", got sent back to task.
- Hit "Cancel" from normal create, got sent back to list.
- Tried to save an invalid task after making changes to CC/Projects, changes
were preserved.
Reviewed By: codeblock
Reviewers: hunterbridges, jungejason, tuomaspelkonen, aran, codeblock
CC: aran, epriestley, codeblock
Differential Revision: 736
2011-07-27 19:46:22 +02:00
|
|
|
'AphrontContextBarView' => 'AphrontView',
|
2011-03-13 01:17:34 +01:00
|
|
|
'AphrontCrumbsView' => 'AphrontView',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontDefaultApplicationConfiguration' => 'AphrontApplicationConfiguration',
|
|
|
|
'AphrontDialogResponse' => 'AphrontResponse',
|
|
|
|
'AphrontDialogView' => 'AphrontView',
|
|
|
|
'AphrontErrorView' => 'AphrontView',
|
2011-05-23 02:06:42 +02:00
|
|
|
'AphrontFilePreviewView' => 'AphrontView',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFileResponse' => 'AphrontResponse',
|
2011-01-26 02:40:21 +01:00
|
|
|
'AphrontFormCheckboxControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormControl' => 'AphrontView',
|
2012-04-04 21:14:10 +02:00
|
|
|
'AphrontFormDateControl' => 'AphrontFormControl',
|
2011-02-05 02:53:14 +01:00
|
|
|
'AphrontFormDividerControl' => 'AphrontFormControl',
|
Improve drag-and-drop uploader
Summary:
Make it discoverable, show uploading progress, show file thumbnails, allow you
to remove files, make it a generic form component.
Test Plan:
Uploaded ducks
Reviewed By: tomo
Reviewers: aran, tomo, jungejason, tuomaspelkonen
CC: anjali, aran, epriestley, tomo
Differential Revision: 334
2011-05-23 01:11:41 +02:00
|
|
|
'AphrontFormDragAndDropUploadControl' => 'AphrontFormControl',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormFileControl' => 'AphrontFormControl',
|
2012-03-16 01:10:19 +01:00
|
|
|
'AphrontFormInsetView' => 'AphrontView',
|
2011-06-10 00:28:29 +02:00
|
|
|
'AphrontFormLayoutView' => 'AphrontView',
|
2011-01-24 20:36:53 +01:00
|
|
|
'AphrontFormMarkupControl' => 'AphrontFormControl',
|
2011-01-31 20:55:26 +01:00
|
|
|
'AphrontFormPasswordControl' => 'AphrontFormControl',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'AphrontFormPolicyControl' => 'AphrontFormControl',
|
Improve Herald personal/global UI/UX
Summary:
- Default "personal" vs "global" choice to "personal".
- Don't show global rules under "My Rules".
- After editing or creating a global rule, redirect back to global rule list.
- Use radio buttons for "personal" vs "global" and add captions explaining the
difference.
- For "global" rules, don't show the owner/author in the rule detail view --
they effectively have no owner (see also D1387).
- For "global" rules, don't show the owner/author in the rule list view, as
above.
- For admin views, show rule type (global vs personal).
Test Plan:
- Created and edited new global and personal rules.
- Viewed "my", "global" and "admin" views.
Reviewers: btrahan, jungejason, nh, xela
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1518
2012-01-31 21:09:29 +01:00
|
|
|
'AphrontFormRadioButtonControl' => 'AphrontFormControl',
|
2011-01-31 20:55:26 +01:00
|
|
|
'AphrontFormRecaptchaControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSelectControl' => 'AphrontFormControl',
|
2011-01-23 03:33:00 +01:00
|
|
|
'AphrontFormStaticControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormSubmitControl' => 'AphrontFormControl',
|
|
|
|
'AphrontFormTextAreaControl' => 'AphrontFormControl',
|
|
|
|
'AphrontFormTextControl' => 'AphrontFormControl',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontFormToggleButtonsControl' => 'AphrontFormControl',
|
2011-01-25 22:48:05 +01:00
|
|
|
'AphrontFormTokenizerControl' => 'AphrontFormControl',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontFormView' => 'AphrontView',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontHTTPSinkTestCase' => 'PhabricatorTestCase',
|
2011-02-20 21:50:28 +01:00
|
|
|
'AphrontHeadsupActionListView' => 'AphrontView',
|
|
|
|
'AphrontHeadsupActionView' => 'AphrontView',
|
2012-03-30 23:12:10 +02:00
|
|
|
'AphrontHeadsupView' => 'AphrontView',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'AphrontIDPagerView' => 'AphrontView',
|
2011-04-30 19:11:41 +02:00
|
|
|
'AphrontIsolatedDatabaseConnection' => 'AphrontDatabaseConnection',
|
|
|
|
'AphrontIsolatedDatabaseConnectionTestCase' => 'PhabricatorTestCase',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontIsolatedHTTPSink' => 'AphrontHTTPSink',
|
2012-02-14 23:51:51 +01:00
|
|
|
'AphrontJSONResponse' => 'AphrontResponse',
|
2011-09-07 23:01:13 +02:00
|
|
|
'AphrontJavelinView' => 'AphrontView',
|
2011-06-08 20:53:10 +02:00
|
|
|
'AphrontKeyboardShortcutsAvailableView' => 'AphrontView',
|
2011-04-04 00:50:06 +02:00
|
|
|
'AphrontListFilterView' => 'AphrontView',
|
2012-02-15 01:23:53 +01:00
|
|
|
'AphrontMiniPanelView' => 'AphrontView',
|
2012-04-07 08:59:14 +02:00
|
|
|
'AphrontMySQLDatabaseConnection' => 'AphrontMySQLDatabaseConnectionBase',
|
|
|
|
'AphrontMySQLDatabaseConnectionBase' => 'AphrontDatabaseConnection',
|
2012-02-07 23:58:37 +01:00
|
|
|
'AphrontMySQLDatabaseConnectionTestCase' => 'PhabricatorTestCase',
|
2012-04-07 08:59:14 +02:00
|
|
|
'AphrontMySQLiDatabaseConnection' => 'AphrontMySQLDatabaseConnectionBase',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontNullView' => 'AphrontView',
|
2012-02-06 18:59:34 +01:00
|
|
|
'AphrontPHPHTTPSink' => 'AphrontHTTPSink',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPageView' => 'AphrontView',
|
2011-04-01 02:06:33 +02:00
|
|
|
'AphrontPagerView' => 'AphrontView',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontPanelView' => 'AphrontView',
|
2012-01-15 20:06:13 +01:00
|
|
|
'AphrontPlainTextResponse' => 'AphrontResponse',
|
2012-03-13 05:39:05 +01:00
|
|
|
'AphrontProxyResponse' => 'AphrontResponse',
|
2011-04-30 09:18:13 +02:00
|
|
|
'AphrontQueryAccessDeniedException' => 'AphrontQueryRecoverableException',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontQueryConnectionException' => 'AphrontQueryException',
|
|
|
|
'AphrontQueryConnectionLostException' => 'AphrontQueryRecoverableException',
|
|
|
|
'AphrontQueryCountException' => 'AphrontQueryException',
|
2011-01-31 06:28:45 +01:00
|
|
|
'AphrontQueryDuplicateKeyException' => 'AphrontQueryException',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontQueryObjectMissingException' => 'AphrontQueryException',
|
|
|
|
'AphrontQueryParameterException' => 'AphrontQueryException',
|
|
|
|
'AphrontQueryRecoverableException' => 'AphrontQueryException',
|
2012-03-05 22:17:21 +01:00
|
|
|
'AphrontQuerySchemaException' => 'AphrontQueryException',
|
2011-01-26 22:21:12 +01:00
|
|
|
'AphrontRedirectException' => 'AphrontException',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontRedirectResponse' => 'AphrontResponse',
|
2011-05-16 20:43:39 +02:00
|
|
|
'AphrontReloadResponse' => 'AphrontRedirectResponse',
|
2011-01-30 18:15:01 +01:00
|
|
|
'AphrontRequestFailureView' => 'AphrontView',
|
2012-01-04 06:57:45 +01:00
|
|
|
'AphrontRequestTestCase' => 'PhabricatorTestCase',
|
2011-12-17 02:08:18 +01:00
|
|
|
'AphrontSideNavFilterView' => 'AphrontView',
|
2011-01-24 18:00:29 +01:00
|
|
|
'AphrontSideNavView' => 'AphrontView',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontTableView' => 'AphrontView',
|
2011-03-23 04:41:02 +01:00
|
|
|
'AphrontTokenizerTemplateView' => 'AphrontView',
|
2011-04-04 04:20:47 +02:00
|
|
|
'AphrontTypeaheadTemplateView' => 'AphrontView',
|
2012-04-24 03:36:25 +02:00
|
|
|
'AphrontUsageException' => 'AphrontException',
|
2011-01-16 22:51:39 +01:00
|
|
|
'AphrontWebpageResponse' => 'AphrontResponse',
|
2011-01-25 18:59:31 +01:00
|
|
|
'CelerityResourceController' => 'AphrontController',
|
2011-11-22 20:36:57 +01:00
|
|
|
'CelerityResourceGraph' => 'AbstractDirectedGraph',
|
Use Celerity to version all static resources
Summary:
We don't use versioned URIs for images, so when they change users may get old versions.
This was a particular issue with the recent logo change, which several users reported cache-related issues from.
Instead, use Celerity to manage image URI versions in addition to CSS/JS.
This is complicated, because we need to rewrite image URIs inside of CSS, which means the hash of a CSS file has to be derived from the current image data. Otherwise, when we updated an image the CSS wouldn't update, so we wouldn't be any better off.
So basically we:
- Find all the "raw" files, and put them into the map.
- Find all the CSS/JS, perform content-altering transformations on it (i.e., not minification) based on the partial map, and then put it into the map based on transformed hashes.
(If we wanted, we could now do CSS variables or whatever for "free", more or less.)
Test Plan:
- Regenerated celerity map, browsed site, verified images generated with versioned URIs.
- Moved "blue" flag image over "green" flag image, regenerated map, verified "green" flag image and the associated CSS changed hashes.
- Added transformation unit tests; ran unit tests.
Reviewers: btrahan, vrana, jungejason
Reviewed By: vrana
CC: aran
Maniphest Tasks: T1073
Differential Revision: https://secure.phabricator.com/D2146
2012-04-08 19:07:51 +02:00
|
|
|
'CelerityResourceTransformerTestCase' => 'PhabricatorTestCase',
|
2011-09-16 20:42:45 +02:00
|
|
|
'ConduitAPI_arcanist_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_arcanist_projectinfo_Method' => 'ConduitAPI_arcanist_Method',
|
2012-03-07 00:12:27 +01:00
|
|
|
'ConduitAPI_audit_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_audit_query_Method' => 'ConduitAPI_audit_Method',
|
2012-02-17 19:21:38 +01:00
|
|
|
'ConduitAPI_chatlog_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_chatlog_query_Method' => 'ConduitAPI_chatlog_Method',
|
|
|
|
'ConduitAPI_chatlog_record_Method' => 'ConduitAPI_chatlog_Method',
|
2011-01-24 20:30:10 +01:00
|
|
|
'ConduitAPI_conduit_connect_Method' => 'ConduitAPIMethod',
|
2011-06-14 21:17:14 +02:00
|
|
|
'ConduitAPI_conduit_getcertificate_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:36:32 +01:00
|
|
|
'ConduitAPI_conduit_ping_Method' => 'ConduitAPIMethod',
|
2011-03-15 21:38:14 +01:00
|
|
|
'ConduitAPI_daemon_launched_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_daemon_log_Method' => 'ConduitAPIMethod',
|
2012-04-24 02:40:57 +02:00
|
|
|
'ConduitAPI_differential_close_Method' => 'ConduitAPIMethod',
|
2011-11-18 18:16:40 +01:00
|
|
|
'ConduitAPI_differential_createcomment_Method' => 'ConduitAPIMethod',
|
2011-01-24 20:01:53 +01:00
|
|
|
'ConduitAPI_differential_creatediff_Method' => 'ConduitAPIMethod',
|
2011-02-06 22:49:23 +01:00
|
|
|
'ConduitAPI_differential_createrevision_Method' => 'ConduitAPIMethod',
|
2011-02-06 23:43:06 +01:00
|
|
|
'ConduitAPI_differential_find_Method' => 'ConduitAPIMethod',
|
2011-04-21 00:29:02 +02:00
|
|
|
'ConduitAPI_differential_getalldiffs_Method' => 'ConduitAPIMethod',
|
2011-02-09 18:41:26 +01:00
|
|
|
'ConduitAPI_differential_getcommitmessage_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:28:03 +01:00
|
|
|
'ConduitAPI_differential_getcommitpaths_Method' => 'ConduitAPIMethod',
|
2011-02-19 07:15:28 +01:00
|
|
|
'ConduitAPI_differential_getdiff_Method' => 'ConduitAPIMethod',
|
2011-04-21 01:38:16 +02:00
|
|
|
'ConduitAPI_differential_getrevision_Method' => 'ConduitAPIMethod',
|
2011-12-12 20:55:55 +01:00
|
|
|
'ConduitAPI_differential_getrevisioncomments_Method' => 'ConduitAPIMethod',
|
2011-04-20 01:24:45 +02:00
|
|
|
'ConduitAPI_differential_getrevisionfeedback_Method' => 'ConduitAPIMethod',
|
2011-02-09 18:48:26 +01:00
|
|
|
'ConduitAPI_differential_markcommitted_Method' => 'ConduitAPIMethod',
|
2011-02-06 22:42:00 +01:00
|
|
|
'ConduitAPI_differential_parsecommitmessage_Method' => 'ConduitAPIMethod',
|
2011-12-02 01:57:06 +01:00
|
|
|
'ConduitAPI_differential_query_Method' => 'ConduitAPIMethod',
|
2011-01-24 21:07:34 +01:00
|
|
|
'ConduitAPI_differential_setdiffproperty_Method' => 'ConduitAPIMethod',
|
2011-02-06 23:00:32 +01:00
|
|
|
'ConduitAPI_differential_updaterevision_Method' => 'ConduitAPIMethod',
|
2011-04-22 03:47:04 +02:00
|
|
|
'ConduitAPI_differential_updatetaskrevisionassoc_Method' => 'ConduitAPIMethod',
|
2011-06-09 01:16:59 +02:00
|
|
|
'ConduitAPI_differential_updateunitresults_Method' => 'ConduitAPIMethod',
|
2011-12-21 18:39:33 +01:00
|
|
|
'ConduitAPI_diffusion_findsymbols_Method' => 'ConduitAPIMethod',
|
2011-04-14 01:39:08 +02:00
|
|
|
'ConduitAPI_diffusion_getcommits_Method' => 'ConduitAPIMethod',
|
2011-05-20 00:36:17 +02:00
|
|
|
'ConduitAPI_diffusion_getrecentcommitsbypath_Method' => 'ConduitAPIMethod',
|
2011-07-05 17:35:18 +02:00
|
|
|
'ConduitAPI_feed_publish_Method' => 'ConduitAPIMethod',
|
2012-02-03 01:44:05 +01:00
|
|
|
'ConduitAPI_feed_query_Method' => 'ConduitAPIMethod',
|
2011-05-21 18:53:50 +02:00
|
|
|
'ConduitAPI_file_download_Method' => 'ConduitAPIMethod',
|
2011-07-29 19:00:16 +02:00
|
|
|
'ConduitAPI_file_info_Method' => 'ConduitAPIMethod',
|
2011-01-24 18:00:29 +01:00
|
|
|
'ConduitAPI_file_upload_Method' => 'ConduitAPIMethod',
|
2012-03-28 01:22:40 +02:00
|
|
|
'ConduitAPI_flag_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_flag_query_Method' => 'ConduitAPI_flag_Method',
|
2012-03-09 21:40:03 +01:00
|
|
|
'ConduitAPI_macro_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_macro_query_Method' => 'ConduitAPI_macro_Method',
|
2011-08-18 00:19:48 +02:00
|
|
|
'ConduitAPI_maniphest_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_maniphest_createtask_Method' => 'ConduitAPI_maniphest_Method',
|
2011-08-27 01:52:57 +02:00
|
|
|
'ConduitAPI_maniphest_find_Method' => 'ConduitAPI_maniphest_Method',
|
2012-01-11 04:51:55 +01:00
|
|
|
'ConduitAPI_maniphest_gettasktransactions_Method' => 'ConduitAPI_maniphest_Method',
|
2011-08-18 00:19:48 +02:00
|
|
|
'ConduitAPI_maniphest_info_Method' => 'ConduitAPI_maniphest_Method',
|
2012-01-06 04:02:50 +01:00
|
|
|
'ConduitAPI_maniphest_update_Method' => 'ConduitAPI_maniphest_Method',
|
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',
|
2011-04-12 06:51:36 +02:00
|
|
|
'ConduitAPI_path_getowners_Method' => 'ConduitAPIMethod',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_phid_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_phid_info_Method' => 'ConduitAPI_phid_Method',
|
2012-02-15 03:26:27 +01:00
|
|
|
'ConduitAPI_phid_query_Method' => 'ConduitAPI_phid_Method',
|
2011-08-26 21:50:28 +02:00
|
|
|
'ConduitAPI_phriction_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_phriction_edit_Method' => 'ConduitAPI_phriction_Method',
|
|
|
|
'ConduitAPI_phriction_history_Method' => 'ConduitAPI_phriction_Method',
|
|
|
|
'ConduitAPI_phriction_info_Method' => 'ConduitAPI_phriction_Method',
|
2012-01-18 01:29:35 +01:00
|
|
|
'ConduitAPI_project_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_project_query_Method' => 'ConduitAPI_project_Method',
|
2012-02-03 01:42:29 +01:00
|
|
|
'ConduitAPI_remarkup_process_Method' => 'ConduitAPIMethod',
|
2011-07-13 04:18:20 +02:00
|
|
|
'ConduitAPI_slowvote_info_Method' => 'ConduitAPIMethod',
|
2011-08-30 21:03:58 +02:00
|
|
|
'ConduitAPI_user_Method' => 'ConduitAPIMethod',
|
|
|
|
'ConduitAPI_user_find_Method' => 'ConduitAPI_user_Method',
|
|
|
|
'ConduitAPI_user_info_Method' => 'ConduitAPI_user_Method',
|
|
|
|
'ConduitAPI_user_whoami_Method' => 'ConduitAPI_user_Method',
|
2011-02-12 01:48:43 +01:00
|
|
|
'DarkConsoleConfigPlugin' => 'DarkConsolePlugin',
|
2011-02-03 07:38:42 +01:00
|
|
|
'DarkConsoleController' => 'PhabricatorController',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsoleErrorLogPlugin' => 'DarkConsolePlugin',
|
2011-09-30 21:54:17 +02:00
|
|
|
'DarkConsoleEventPlugin' => 'DarkConsolePlugin',
|
2011-11-10 02:23:33 +01:00
|
|
|
'DarkConsoleEventPluginAPI' => 'PhutilEventListener',
|
2011-02-02 22:48:52 +01:00
|
|
|
'DarkConsoleRequestPlugin' => 'DarkConsolePlugin',
|
|
|
|
'DarkConsoleServicesPlugin' => 'DarkConsolePlugin',
|
|
|
|
'DarkConsoleXHProfPlugin' => 'DarkConsolePlugin',
|
Improve behavior when user submits a no-op action in Differential
Summary:
See T730 and the slightly-less-pretty version of this in D1398.
When a user takes an action in Differential that has no effect (for instance,
accepting an already-accepted revision), prompt them:
Action Has No Effect
You can not accept this revision because it has already been accepted.
Do you want to post the feedback anyway, as a normal comment?
[Cancel] [Post as Comment]
If they have no comment text, the dialog only says "Cancel".
I think this is probably the best way to balance all the concerns here -- it
might occasionally be a little annoying, but that should be rare, and it should
never be confusing (the current workflow is extremely confusing).
This also fixes the issue where you can add all sorts of CCs who are already
part of the revision, either explicitly or via mentions.
Test Plan:
Posted some has-effect and has-no-effect comments, made different
choices in the dialog, everything seems to work OK?
Reviewers: vrana, btrahan, jungejason
Reviewed By: vrana
CC: aran, vrana
Maniphest Tasks: T730
Differential Revision: https://secure.phabricator.com/D1403
2012-01-14 20:39:22 +01:00
|
|
|
'DifferentialActionHasNoEffectException' => 'DifferentialException',
|
2011-01-30 20:02:22 +01:00
|
|
|
'DifferentialAddCommentView' => 'AphrontView',
|
2011-09-14 19:59:52 +02:00
|
|
|
'DifferentialAffectedPath' => 'DifferentialDAO',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialApplyPatchFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialArcanistProjectFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-03-07 00:10:35 +01:00
|
|
|
'DifferentialAuditorsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialAuthorFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialAuxiliaryField' => 'DifferentialDAO',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialBlameRevisionFieldSpecification' => 'DifferentialFieldSpecification',
|
2012-02-07 01:34:25 +01:00
|
|
|
'DifferentialBranchFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialCCWelcomeMail' => 'DifferentialReviewRequestMail',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialCCsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialChangeset' => 'DifferentialDAO',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialChangesetDetailView' => 'AphrontView',
|
2011-01-25 20:57:47 +01:00
|
|
|
'DifferentialChangesetListView' => 'AphrontView',
|
2011-01-25 00:52:35 +01:00
|
|
|
'DifferentialChangesetViewController' => 'DifferentialController',
|
2011-01-30 19:37:36 +01:00
|
|
|
'DifferentialComment' => 'DifferentialDAO',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentMail' => 'DifferentialMail',
|
2011-02-01 03:05:20 +01:00
|
|
|
'DifferentialCommentPreviewController' => 'DifferentialController',
|
2011-01-30 21:08:40 +01:00
|
|
|
'DifferentialCommentSaveController' => 'DifferentialController',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialCommitsFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialController' => 'PhabricatorController',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDAO' => 'PhabricatorLiskDAO',
|
2012-02-20 14:38:21 +01:00
|
|
|
'DifferentialDateCreatedFieldSpecification' => 'DifferentialFieldSpecification',
|
|
|
|
'DifferentialDateModifiedFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-10 20:29:08 +02:00
|
|
|
'DifferentialDefaultFieldSelector' => 'DifferentialFieldSelector',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialDependenciesFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialDiff' => 'DifferentialDAO',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialDiffContentMail' => 'DifferentialMail',
|
2011-02-05 21:20:18 +01:00
|
|
|
'DifferentialDiffCreateController' => 'DifferentialController',
|
2011-01-24 21:07:34 +01:00
|
|
|
'DifferentialDiffProperty' => 'DifferentialDAO',
|
2011-01-24 22:18:41 +01:00
|
|
|
'DifferentialDiffTableOfContentsView' => 'AphrontView',
|
|
|
|
'DifferentialDiffViewController' => 'DifferentialController',
|
2011-05-01 04:40:05 +02:00
|
|
|
'DifferentialExceptionMail' => 'DifferentialMail',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialExportPatchFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialGitSVNIDFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialHostFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialHunk' => 'DifferentialDAO',
|
2011-02-02 00:52:04 +01:00
|
|
|
'DifferentialInlineComment' => 'DifferentialDAO',
|
Add inline comments to Diffusion/Audit
Summary:
- Add inline comments to Audits, like Differential.
- Creates new storage for the comments in the Audits database.
- Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment.
- Defines an Interface which Differential and Audit comments conform to.
- Makes consumers of DifferentialInlineComments consume objects which implement that interface instead.
- Adds save
NOTE: Some features are still missing! Wanted to cut this off before it got crazy:
- Inline comments aren't shown in the main comment list.
- Inline comments aren't shown in the emails.
- Inline comments aren't previewed.
I'll followup with those but this was getting pretty big.
@vrana, does the SQL change look correct?
Test Plan:
- Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs.
- Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran, epriestley
Maniphest Tasks: T904
Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
|
|
|
'DifferentialInlineCommentEditController' => 'PhabricatorInlineCommentController',
|
2012-02-29 23:28:48 +01:00
|
|
|
'DifferentialInlineCommentEditView' => 'AphrontView',
|
2011-02-03 04:38:43 +01:00
|
|
|
'DifferentialInlineCommentPreviewController' => 'DifferentialController',
|
2011-02-02 01:42:36 +01:00
|
|
|
'DifferentialInlineCommentView' => 'AphrontView',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialLinesFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialLintFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-30 20:34:07 +02:00
|
|
|
'DifferentialLocalCommitsView' => 'AphrontView',
|
2011-08-14 21:33:54 +02:00
|
|
|
'DifferentialManiphestTasksFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialNewDiffMail' => 'DifferentialReviewRequestMail',
|
2011-08-14 20:29:56 +02:00
|
|
|
'DifferentialPathFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-06-08 21:39:03 +02:00
|
|
|
'DifferentialPrimaryPaneView' => 'AphrontView',
|
2011-05-10 01:31:26 +02:00
|
|
|
'DifferentialReplyHandler' => 'PhabricatorMailReplyHandler',
|
2011-08-11 00:36:18 +02:00
|
|
|
'DifferentialRevertPlanFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 02:17:19 +01:00
|
|
|
'DifferentialReviewRequestMail' => 'DifferentialMail',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialReviewedByFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialReviewersFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-24 20:01:53 +01:00
|
|
|
'DifferentialRevision' => 'DifferentialDAO',
|
2011-01-30 19:37:36 +01:00
|
|
|
'DifferentialRevisionCommentListView' => 'AphrontView',
|
|
|
|
'DifferentialRevisionCommentView' => 'AphrontView',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionDetailView' => 'AphrontView',
|
2011-01-25 22:26:09 +01:00
|
|
|
'DifferentialRevisionEditController' => 'DifferentialController',
|
Emit full URIs to identify Differential revisions
Summary:
- Previously, used IDs like "33" to match a commit to a Differential revision.
This has a namespacing problem because we now have an arbitrarily large number
of Phabricator installs in the world, and they may want to track commits from
other installs.
- In Differential, parse raw IDs or full URIs. Emit only full URIs.
- In Repositories, parse only full URIs.
- This might cause a few commits to not be picked up in rare circumstances.
Users can fix them with "arc mark-committed". This should be exceedingly rare
because of hash matching.
- There are some caveats for reparsing older repositories, see comments
inline. I don't think there's much broad impact here.
Test Plan:
- Created a new revision, got a full URI.
- Updated revision, worked correctly.
- Ran unit tests.
- Monkeyed with "Differential Revision" field.
- Reviewers: btrahan, jungejason
Reviewers: btrahan, jungejason
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Maniphest Tasks: T54, T692
Differential Revision: 1250
2011-12-21 00:40:24 +01:00
|
|
|
'DifferentialRevisionIDFieldParserTestCase' => 'PhabricatorTestCase',
|
2011-08-15 03:52:09 +02:00
|
|
|
'DifferentialRevisionIDFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-26 00:19:06 +01:00
|
|
|
'DifferentialRevisionListController' => 'DifferentialController',
|
2011-10-02 20:42:41 +02:00
|
|
|
'DifferentialRevisionListView' => 'AphrontView',
|
2012-02-19 05:16:35 +01:00
|
|
|
'DifferentialRevisionStatsController' => 'DifferentialController',
|
|
|
|
'DifferentialRevisionStatsView' => 'AphrontView',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialRevisionStatusFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-01-27 23:55:52 +01:00
|
|
|
'DifferentialRevisionUpdateHistoryView' => 'AphrontView',
|
|
|
|
'DifferentialRevisionViewController' => 'DifferentialController',
|
2011-02-19 23:36:13 +01:00
|
|
|
'DifferentialSubscribeController' => 'DifferentialController',
|
2011-08-14 23:28:08 +02:00
|
|
|
'DifferentialSummaryFieldSpecification' => 'DifferentialFieldSpecification',
|
|
|
|
'DifferentialTestPlanFieldSpecification' => 'DifferentialFieldSpecification',
|
|
|
|
'DifferentialTitleFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-08-14 22:55:30 +02:00
|
|
|
'DifferentialUnitFieldSpecification' => 'DifferentialFieldSpecification',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionBranchTableView' => 'DiffusionView',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionBrowseController' => 'DiffusionController',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionBrowseFileController' => 'DiffusionController',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionBrowseTableView' => 'DiffusionView',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionChangeController' => 'DiffusionController',
|
2012-02-24 23:14:39 +01:00
|
|
|
'DiffusionCommentListView' => 'AphrontView',
|
|
|
|
'DiffusionCommentView' => 'AphrontView',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionCommitChangeTableView' => 'DiffusionView',
|
2011-03-11 18:34:22 +01:00
|
|
|
'DiffusionCommitController' => 'DiffusionController',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionCommitParentsQuery' => 'DiffusionQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionCommitTagsQuery' => 'DiffusionQuery',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionContainsQuery' => 'DiffusionQuery',
|
2011-03-08 00:13:36 +01:00
|
|
|
'DiffusionController' => 'PhabricatorController',
|
2011-03-31 02:36:16 +02:00
|
|
|
'DiffusionDiffController' => 'DiffusionController',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'DiffusionDiffQuery' => 'DiffusionQuery',
|
2012-02-03 01:42:29 +01:00
|
|
|
'DiffusionEmptyResultView' => 'DiffusionView',
|
Improve Diffusion behavior for externals
Summary:
- Feature request from Airtime that I missed in the feedback notes, came up yesterday.
- Identify git submodules as "FILE_SUBMODULE", not "FILE_NORMAL".
- Link git submodules to an external resolver endpoint, which tries to find commits in tracked repositories.
- Identify git symlinks as "FILE_SYMLINK", not "FILE_NORMAL".
- Add folder, file, symlink and externals icons.
Test Plan:
- externals/javelin is now identified as a submoudule and links to Javelin, not identified as a file and links to error.
- bin/phd is now identified as a symlink.
- Interfaces have pretty icons.
Reviewers: btrahan, cpiro, ddfisher, keebuhm, allenjohnashton
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1975
2012-03-21 22:01:20 +01:00
|
|
|
'DiffusionExternalController' => 'DiffusionController',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DiffusionFileContentQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionGitBranchQuery' => 'DiffusionBranchQuery',
|
2011-12-22 21:24:12 +01:00
|
|
|
'DiffusionGitBranchQueryTestCase' => 'PhabricatorTestCase',
|
2011-03-08 02:25:47 +01:00
|
|
|
'DiffusionGitBrowseQuery' => 'DiffusionBrowseQuery',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionGitCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionGitCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionGitContainsQuery' => 'DiffusionContainsQuery',
|
2011-03-31 03:17:36 +02:00
|
|
|
'DiffusionGitDiffQuery' => 'DiffusionDiffQuery',
|
2011-03-08 18:54:55 +01:00
|
|
|
'DiffusionGitFileContentQuery' => 'DiffusionFileContentQuery',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionGitHistoryQuery' => 'DiffusionHistoryQuery',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionGitLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionGitMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionGitRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
|
2011-03-08 23:29:02 +01:00
|
|
|
'DiffusionGitRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionGitTagListQuery' => 'DiffusionTagListQuery',
|
2011-03-09 02:31:44 +01:00
|
|
|
'DiffusionHistoryController' => 'DiffusionController',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionHistoryQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionHistoryTableView' => 'DiffusionView',
|
2011-03-08 00:13:36 +01:00
|
|
|
'DiffusionHomeController' => 'DiffusionController',
|
Add inline comments to Diffusion/Audit
Summary:
- Add inline comments to Audits, like Differential.
- Creates new storage for the comments in the Audits database.
- Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment.
- Defines an Interface which Differential and Audit comments conform to.
- Makes consumers of DifferentialInlineComments consume objects which implement that interface instead.
- Adds save
NOTE: Some features are still missing! Wanted to cut this off before it got crazy:
- Inline comments aren't shown in the main comment list.
- Inline comments aren't shown in the emails.
- Inline comments aren't previewed.
I'll followup with those but this was getting pretty big.
@vrana, does the SQL change look correct?
Test Plan:
- Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs.
- Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran, epriestley
Maniphest Tasks: T904
Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
|
|
|
'DiffusionInlineCommentController' => 'PhabricatorInlineCommentController',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionLastModifiedController' => 'DiffusionController',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'DiffusionLastModifiedQuery' => 'DiffusionQuery',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialBranchQuery' => 'DiffusionBranchQuery',
|
|
|
|
'DiffusionMercurialBrowseQuery' => 'DiffusionBrowseQuery',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionMercurialCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionMercurialCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
2012-01-19 20:49:51 +01:00
|
|
|
'DiffusionMercurialContainsQuery' => 'DiffusionContainsQuery',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialDiffQuery' => 'DiffusionDiffQuery',
|
|
|
|
'DiffusionMercurialFileContentQuery' => 'DiffusionFileContentQuery',
|
|
|
|
'DiffusionMercurialHistoryQuery' => 'DiffusionHistoryQuery',
|
|
|
|
'DiffusionMercurialLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMercurialMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionMercurialRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
|
Basic support for Mercurial in Diffusion
Summary: Change import script plus almost all the view stuff. Still some rough
edges but this seems to mostly work. Blame is currently unsupported but I think
everything else works properly.
Test Plan:
Imported the hg repository itself. It doesn't immediately seem completely
broken. Here are some screens:
https://secure.phabricator.com/file/view/PHID-FILE-1438b71cc7c4a2eb4569/
https://secure.phabricator.com/file/view/PHID-FILE-3cec4f72f39e7de2d041/
https://secure.phabricator.com/file/view/PHID-FILE-2ea4883f160e8e5098f9/
https://secure.phabricator.com/file/view/PHID-FILE-35f751a36ebf65399ade/
All the parsers were able to churn through it without errors.
Ran the new "reparse.php" script in various one-commit and repository modes.
Browsed/imported some git repos for good measure.
NOTE: The hg repository is only 15,000 commits and around 1,000 files.
Performance is okay but hg doesn't provide performant, native APIs to get some
data efficiently so we have to do some dumb stuff. If some of these interfaces
are cripplingly slow or whatever, let me know and we can start bundling some
Mercurial extensions with Arcanist.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde, epriestley
Differential Revision: 960
2011-09-26 20:07:38 +02:00
|
|
|
'DiffusionMercurialRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionMercurialTagListQuery' => 'DiffusionTagListQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionMergedCommitsQuery' => 'DiffusionQuery',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathCompleteController' => 'DiffusionController',
|
2011-09-14 20:23:39 +02:00
|
|
|
'DiffusionPathQueryTestCase' => 'PhabricatorTestCase',
|
2011-04-04 04:20:47 +02:00
|
|
|
'DiffusionPathValidateController' => 'DiffusionController',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionRenameHistoryQuery' => 'DiffusionQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionRepositoryController' => 'DiffusionController',
|
|
|
|
'DiffusionSvnBrowseQuery' => 'DiffusionBrowseQuery',
|
2012-03-26 21:21:48 +02:00
|
|
|
'DiffusionSvnCommitParentsQuery' => 'DiffusionCommitParentsQuery',
|
2012-04-24 03:36:25 +02:00
|
|
|
'DiffusionSvnCommitTagsQuery' => 'DiffusionCommitTagsQuery',
|
2012-03-24 20:52:14 +01:00
|
|
|
'DiffusionSvnContainsQuery' => 'DiffusionContainsQuery',
|
2011-03-31 02:36:16 +02:00
|
|
|
'DiffusionSvnDiffQuery' => 'DiffusionDiffQuery',
|
2011-03-14 06:03:30 +01:00
|
|
|
'DiffusionSvnFileContentQuery' => 'DiffusionFileContentQuery',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionSvnHistoryQuery' => 'DiffusionHistoryQuery',
|
2011-03-31 08:27:06 +02:00
|
|
|
'DiffusionSvnLastModifiedQuery' => 'DiffusionLastModifiedQuery',
|
2012-03-23 23:32:26 +01:00
|
|
|
'DiffusionSvnMergedCommitsQuery' => 'DiffusionMergedCommitsQuery',
|
2012-04-24 03:16:38 +02:00
|
|
|
'DiffusionSvnRenameHistoryQuery' => 'DiffusionRenameHistoryQuery',
|
2011-03-23 03:34:47 +01:00
|
|
|
'DiffusionSvnRequest' => 'DiffusionRequest',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionSvnTagListQuery' => 'DiffusionTagListQuery',
|
2011-09-05 19:43:24 +02:00
|
|
|
'DiffusionSymbolController' => 'DiffusionController',
|
2012-04-19 18:39:19 +02:00
|
|
|
'DiffusionTagListController' => 'DiffusionController',
|
2012-04-18 17:02:08 +02:00
|
|
|
'DiffusionTagListQuery' => 'DiffusionQuery',
|
|
|
|
'DiffusionTagListView' => 'DiffusionView',
|
Fix many encoding and architecture problems in Diffusion request and URI handling
Summary:
Diffusion request/uri handling is currently a big, hastily ported mess. In particular, it has:
- Tons and tons of duplicated code.
- Bugs with handling unusual branch and file names.
- An excessively large (and yet insufficiently expressive) API on DiffusionRequest, including a nonsensical concrete base class.
- Other tools were doing hacky things like passing ":" branch names.
This diff attempts to fix these issues.
- Make the base class abstract (it was concrete ONLY for "/diffusion/").
- Move all URI generation to DiffusionRequest. Make the core static. Add unit tests.
- Delete the 300 copies of URI generation code throughout Diffusion.
- Move all URI parsing to DiffusionRequest. Make the core static. Add unit tests.
- Add an appropriate static initializer for other callers.
- Convert all code calling `newFromAphrontRequestDictionary` outside of Diffusion to the new `newFromDictionary` API.
- Refactor static initializers to be sensibly-sized.
- Refactor derived DiffusionRequest classes to remove duplicated code.
- Properly encode branch names (fixes branches with "/", see <https://github.com/facebook/phabricator/issues/100>).
- Properly encode path names (fixes issues in D1742).
- Properly escape delimiter characters ";" and "$" in path names so files like "$100" are not interpreted as "line 100".
- Fix a couple warnings.
- Fix a couple lint issues.
- Fix a bug where we would not parse filenames with spaces in them correctly in the Git browse query.
- Fix a bug where Git change queries would fail unnecessarily.
- Provide or improve some documentation.
This thing is pretty gigantic but also kind of hard to split up. If it's unreasonably difficult to review, let me know and I can take a stab at it though.
This supplants D1742.
Test Plan:
- Used home, repository, branch, browse, change, history, diff (ajax), lastmodified (ajax) views of Diffusion.
- Used Owners typeaheads and search.
- Used diffusion.getrecentcommitsbypath method.
- Pushed a change to an absurdly-named file on an absurdly-named branch, everything worked properly.
{F9185}
Reviewers: nh, vrana, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D1921
2012-03-20 03:52:14 +01:00
|
|
|
'DiffusionURITestCase' => 'ArcanistPhutilTestCase',
|
2011-03-13 01:17:34 +01:00
|
|
|
'DiffusionView' => 'AphrontView',
|
2012-01-24 01:58:38 +01:00
|
|
|
'DrydockAllocatorWorker' => 'PhabricatorWorker',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockApacheWebrootBlueprint' => 'DrydockBlueprint',
|
|
|
|
'DrydockApacheWebrootInterface' => 'DrydockWebrootInterface',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockCommandInterface' => 'DrydockInterface',
|
|
|
|
'DrydockController' => 'PhabricatorController',
|
|
|
|
'DrydockDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'DrydockEC2HostBlueprint' => 'DrydockRemoteHostBlueprint',
|
|
|
|
'DrydockLease' => 'DrydockDAO',
|
|
|
|
'DrydockLeaseListController' => 'DrydockController',
|
|
|
|
'DrydockLeaseStatus' => 'DrydockConstants',
|
|
|
|
'DrydockLocalCommandInterface' => 'DrydockCommandInterface',
|
|
|
|
'DrydockLocalHostBlueprint' => 'DrydockBlueprint',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockLog' => 'DrydockDAO',
|
|
|
|
'DrydockLogController' => 'DrydockController',
|
|
|
|
'DrydockLogQuery' => 'PhabricatorOffsetPagedQuery',
|
|
|
|
'DrydockPhabricatorApplicationBlueprint' => 'DrydockBlueprint',
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
'DrydockRemoteHostBlueprint' => 'DrydockBlueprint',
|
|
|
|
'DrydockResource' => 'DrydockDAO',
|
|
|
|
'DrydockResourceAllocateController' => 'DrydockController',
|
|
|
|
'DrydockResourceListController' => 'DrydockController',
|
|
|
|
'DrydockResourceStatus' => 'DrydockConstants',
|
|
|
|
'DrydockSSHCommandInterface' => 'DrydockCommandInterface',
|
2012-03-27 05:54:26 +02:00
|
|
|
'DrydockWebrootInterface' => 'DrydockInterface',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldAction' => 'HeraldDAO',
|
|
|
|
'HeraldApplyTranscript' => 'HeraldDAO',
|
2011-04-04 08:23:36 +02:00
|
|
|
'HeraldCommitAdapter' => 'HeraldObjectAdapter',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldCondition' => 'HeraldDAO',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldController' => 'PhabricatorController',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldDAO' => 'PhabricatorLiskDAO',
|
2011-03-24 19:07:36 +01:00
|
|
|
'HeraldDeleteController' => 'HeraldController',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldDifferentialRevisionAdapter' => 'HeraldObjectAdapter',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldDryRunAdapter' => 'HeraldObjectAdapter',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'HeraldEditLogQuery' => 'PhabricatorOffsetPagedQuery',
|
2011-03-22 21:49:46 +01:00
|
|
|
'HeraldHomeController' => 'HeraldController',
|
2011-03-22 22:34:38 +01:00
|
|
|
'HeraldNewController' => 'HeraldController',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldRule' => 'HeraldDAO',
|
2011-03-22 23:27:52 +01:00
|
|
|
'HeraldRuleController' => 'HeraldController',
|
2012-01-30 20:51:23 +01:00
|
|
|
'HeraldRuleEdit' => 'HeraldDAO',
|
|
|
|
'HeraldRuleEditHistoryController' => 'HeraldController',
|
|
|
|
'HeraldRuleEditHistoryView' => 'AphrontView',
|
2011-11-06 09:07:04 +01:00
|
|
|
'HeraldRuleListView' => 'AphrontView',
|
General Herald refactoring pass
Summary:
**Who can delete global rules?**: I discussed this with @jungejason. The current behavior is that the rule author or any administrator can delete a global rule, but this
isn't consistent with who can edit a rule (anyone) and doesn't really make much sense (it's an artifact of the global/personal split). I proposed that anyone can delete a
rule but we don't actually delete them, and log the deletion. However, when it came time to actually write the code for this I backed off a bit and continued actually
deleting the rules -- I think this does a reasonable job of balancing accountability with complexity. So the new impelmentation is:
- Personal rules can be deleted only by their owners.
- Global rules can be deleted by any user.
- All deletes are logged.
- Logs are more detailed.
- All logged actions can be viewed in aggregate.
**Minor Cleanup**
- Merged `HomeController` and `AllController`.
- Moved most queries to Query classes.
- Use AphrontFormSelectControl::renderSelectTag() where appropriate (this is a fairly recent addition).
- Use an AphrontErrorView to render the dry run notice (this didn't exist when I ported).
- Reenable some transaction code (this works again now).
- Removed the ability for admins to change rule authors (this was a little buggy, messy, and doesn't make tons of sense after the personal/global rule split).
- Rules which depend on other rules now display the right options (all global rules, all your personal rules for personal rules).
- Fix a bug in AphrontTableView where the "no data" cell would be rendered too wide if some columns are not visible.
- Allow selectFilter() in AphrontNavFilterView to be called without a 'default' argument.
Test Plan:
- Browsed, created, edited, deleted personal and gules.
- Verified generated logs.
- Did some dry runs.
- Verified transcript list and transcript details.
- Created/edited all/any rules; created/edited once/every time rules.
- Filtered admin views by users.
Reviewers: jungejason, btrahan
Reviewed By: btrahan
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D2040
2012-03-30 19:49:55 +02:00
|
|
|
'HeraldRuleQuery' => 'PhabricatorOffsetPagedQuery',
|
2011-03-24 21:49:21 +01:00
|
|
|
'HeraldTestConsoleController' => 'HeraldController',
|
2011-03-22 21:22:40 +01:00
|
|
|
'HeraldTranscript' => 'HeraldDAO',
|
2011-03-25 05:32:26 +01:00
|
|
|
'HeraldTranscriptController' => 'HeraldController',
|
|
|
|
'HeraldTranscriptListController' => 'HeraldController',
|
2011-09-07 23:01:13 +02:00
|
|
|
'JavelinReactorExample' => 'PhabricatorUIExample',
|
|
|
|
'JavelinViewExample' => 'PhabricatorUIExample',
|
|
|
|
'JavelinViewExampleServerView' => 'AphrontView',
|
2011-04-30 19:11:59 +02:00
|
|
|
'LiskIsolationTestCase' => 'PhabricatorTestCase',
|
|
|
|
'LiskIsolationTestDAO' => 'LiskDAO',
|
2011-12-17 22:27:11 +01:00
|
|
|
'ManiphestAction' => 'PhrictionConstants',
|
2011-07-27 18:49:50 +02:00
|
|
|
'ManiphestAuxiliaryFieldDefaultSpecification' => 'ManiphestAuxiliaryFieldSpecification',
|
2012-02-24 22:00:48 +01:00
|
|
|
'ManiphestBatchEditController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestController' => 'PhabricatorController',
|
|
|
|
'ManiphestDAO' => 'PhabricatorLiskDAO',
|
2011-08-05 18:44:43 +02:00
|
|
|
'ManiphestDefaultTaskExtensions' => 'ManiphestTaskExtensions',
|
2012-02-29 06:07:12 +01:00
|
|
|
'ManiphestExportController' => 'ManiphestController',
|
2011-05-10 01:31:26 +02:00
|
|
|
'ManiphestReplyHandler' => 'PhabricatorMailReplyHandler',
|
2012-02-08 18:47:14 +01:00
|
|
|
'ManiphestReportController' => 'ManiphestController',
|
2012-04-10 18:46:04 +02:00
|
|
|
'ManiphestSavedQuery' => 'ManiphestDAO',
|
|
|
|
'ManiphestSavedQueryDeleteController' => 'ManiphestController',
|
|
|
|
'ManiphestSavedQueryEditController' => 'ManiphestController',
|
|
|
|
'ManiphestSavedQueryListController' => 'ManiphestController',
|
2012-04-02 21:12:04 +02:00
|
|
|
'ManiphestSubpriorityController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTask' => 'ManiphestDAO',
|
2011-07-26 00:34:56 +02:00
|
|
|
'ManiphestTaskAuxiliaryStorage' => 'ManiphestDAO',
|
2011-05-21 03:56:18 +02:00
|
|
|
'ManiphestTaskDescriptionChangeController' => 'ManiphestController',
|
2012-01-25 20:23:00 +01:00
|
|
|
'ManiphestTaskDescriptionPreviewController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskDetailController' => 'ManiphestController',
|
2011-02-20 23:15:53 +01:00
|
|
|
'ManiphestTaskEditController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTaskListController' => 'ManiphestController',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskListView' => 'ManiphestView',
|
|
|
|
'ManiphestTaskOwner' => 'ManiphestConstants',
|
|
|
|
'ManiphestTaskPriority' => 'ManiphestConstants',
|
2011-06-30 01:16:33 +02:00
|
|
|
'ManiphestTaskProject' => 'ManiphestDAO',
|
2012-04-02 19:27:31 +02:00
|
|
|
'ManiphestTaskProjectsView' => 'ManiphestView',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskStatus' => 'ManiphestConstants',
|
2011-07-07 19:24:49 +02:00
|
|
|
'ManiphestTaskSubscriber' => 'ManiphestDAO',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTaskSummaryView' => 'ManiphestView',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTransaction' => 'ManiphestDAO',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTransactionDetailView' => 'ManiphestView',
|
|
|
|
'ManiphestTransactionListView' => 'ManiphestView',
|
2011-05-10 17:29:28 +02:00
|
|
|
'ManiphestTransactionPreviewController' => 'ManiphestController',
|
2011-02-08 19:53:59 +01:00
|
|
|
'ManiphestTransactionSaveController' => 'ManiphestController',
|
2011-07-04 22:04:22 +02:00
|
|
|
'ManiphestTransactionType' => 'ManiphestConstants',
|
|
|
|
'ManiphestView' => 'AphrontView',
|
Add email preferences to receive fewer less-important notifications
Summary:
A few similar requests have come in across several tools and use cases that I
think this does a reasonable job of resolving.
We currently send one email for each update an object receives, but these aren't
always appreciated:
- Asana does post-commit review via Differential, so the "committed" mails are
useless.
- Quora wants to make project category edits to bugs without spamming people
attached to them.
- Some users in general are very sensitive to email volumes, and this gives us
a good way to reduce the volumes without incurring the complexity of
delayed-send-batching.
The technical mechanism is basically:
- Mail may optionally have "mail tags", which indicate content in the mail
(e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which
contains a priority change, a CC change, and a comment).
- If a mail has tags, remove any recipients who have opted out of all the
tags.
- Some tags can't be opted out of via the UI, so this ensures that important
email is still delivered (e.g., cc + assign + comment is always delivered
because you can't opt out of "assign" or "comment").
Test Plan:
- Disabled all mail tags in the web UI.
- Used test console to send myself mail with an opt-outable tag, it was
immediately dropped.
- Used test console to send myself mail with an opt-outable tag and a custom
tag, it was delivered.
- Made Differential updates affecting CCs with and without comments, got
appropriate delivery.
- Made Maniphest updates affecting project, priority and CCs with and without
comments, got appropriate delivery.
- Verified mail headers in all cases.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, epriestley, moskov
Maniphest Tasks: T616, T855
Differential Revision: https://secure.phabricator.com/D1635
2012-02-18 07:57:07 +01:00
|
|
|
'MetaMTANotificationType' => 'MetaMTAConstants',
|
2011-01-30 01:16:09 +01:00
|
|
|
'Phabricator404Controller' => 'PhabricatorController',
|
2012-03-07 05:14:03 +01:00
|
|
|
'PhabricatorAphlictTestPageController' => 'PhabricatorNotificationsController',
|
2012-02-25 00:04:53 +01:00
|
|
|
'PhabricatorAuditAddCommentController' => 'PhabricatorAuditController',
|
Add Basic Auditing Functionalities
Summary:
add basic auditing functionalities. For the related commits for a
package, we detect the following conditions which might be suspicious to the
owners of the package:
* no revision specified
* revision not found
* author not match
* reviewedby not match
* owners not involved
* commit author not recognized
The owners of the package can change the status of the audit entries by
accepting it or specify concern.
The owner can turn on/off the auditing for a package.
Test Plan:
* verified that non-owner cannot see the details of the audit and cannot modify
it
* verified that all the audit reasons can be detected
* tested dropdown filtering and package search
* verified really normal change not detected
* verified accept/concern a commit
* tested enable/disable a package for auditing
* verified one audit applies to all <commit, packages> to the packages the
auditor owns
* verified that re-parsing a commit won't have effect if there exists a
relationship for <commit, package> already
Reviewers: epriestley, nh
Reviewed By: epriestley
CC: aran, benmathews, btrahan, mpodobnik, prithvi, TomL, epriestley
Differential Revision: 1242
2011-12-18 00:52:54 +01:00
|
|
|
'PhabricatorAuditComment' => 'PhabricatorAuditDAO',
|
2012-02-29 06:10:39 +01:00
|
|
|
'PhabricatorAuditCommitListView' => 'AphrontView',
|
Add Basic Auditing Functionalities
Summary:
add basic auditing functionalities. For the related commits for a
package, we detect the following conditions which might be suspicious to the
owners of the package:
* no revision specified
* revision not found
* author not match
* reviewedby not match
* owners not involved
* commit author not recognized
The owners of the package can change the status of the audit entries by
accepting it or specify concern.
The owner can turn on/off the auditing for a package.
Test Plan:
* verified that non-owner cannot see the details of the audit and cannot modify
it
* verified that all the audit reasons can be detected
* tested dropdown filtering and package search
* verified really normal change not detected
* verified accept/concern a commit
* tested enable/disable a package for auditing
* verified one audit applies to all <commit, packages> to the packages the
auditor owns
* verified that re-parsing a commit won't have effect if there exists a
relationship for <commit, package> already
Reviewers: epriestley, nh
Reviewed By: epriestley
CC: aran, benmathews, btrahan, mpodobnik, prithvi, TomL, epriestley
Differential Revision: 1242
2011-12-18 00:52:54 +01:00
|
|
|
'PhabricatorAuditController' => 'PhabricatorController',
|
|
|
|
'PhabricatorAuditDAO' => 'PhabricatorLiskDAO',
|
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
|
|
|
'PhabricatorAuditInlineComment' => 'PhabricatorAuditDAO',
|
2012-02-24 22:02:14 +01:00
|
|
|
'PhabricatorAuditListController' => 'PhabricatorAuditController',
|
|
|
|
'PhabricatorAuditListView' => 'AphrontView',
|
2012-02-27 22:00:23 +01:00
|
|
|
'PhabricatorAuditPreviewController' => 'PhabricatorAuditController',
|
2012-02-27 21:57:57 +01:00
|
|
|
'PhabricatorAuditReplyHandler' => 'PhabricatorMailReplyHandler',
|
2011-01-26 22:21:12 +01:00
|
|
|
'PhabricatorAuthController' => 'PhabricatorController',
|
Build a basic calendar view
Summary:
This is a very small step toward building a Status and possibly an Oncall tool.
Build a calendar view which renders months.
Much of my hesitance to bang these tools out is that dealing with
dates/calendaring is basically horrible, so I'm trying to ease into it.
This calendar is locale-aware and all that jazz.
Test Plan:
- See:
https://secure.phabricator.com/file/view/PHID-FILE-c07a9c663a7d040d2529/
- Verified that months have the right number of days, today is the right day
of the week, months begin on the day after previous months end on, etc.
Reviewed By: aran
Reviewers: jungejason, tuomaspelkonen, aran
Commenters: cwbeck, jungejason
CC: blair, aran, epriestley, cwbeck, jungejason
Differential Revision: 791
2011-08-08 03:26:31 +02:00
|
|
|
'PhabricatorCalendarBrowseController' => 'PhabricatorCalendarController',
|
|
|
|
'PhabricatorCalendarController' => 'PhabricatorController',
|
2012-03-13 05:39:05 +01:00
|
|
|
'PhabricatorChangesetResponse' => 'AphrontProxyResponse',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorChatLogChannelListController' => 'PhabricatorChatLogController',
|
|
|
|
'PhabricatorChatLogChannelLogController' => 'PhabricatorChatLogController',
|
|
|
|
'PhabricatorChatLogController' => 'PhabricatorController',
|
|
|
|
'PhabricatorChatLogDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorChatLogEvent' => 'PhabricatorChatLogDAO',
|
|
|
|
'PhabricatorChatLogEventType' => 'PhabricatorChatLogConstants',
|
2012-03-30 23:12:10 +02:00
|
|
|
'PhabricatorChatLogQuery' => 'PhabricatorOffsetPagedQuery',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitAPIController' => 'PhabricatorConduitController',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitCertificateToken' => 'PhabricatorConduitDAO',
|
2011-01-24 18:00:29 +01:00
|
|
|
'PhabricatorConduitConnectionLog' => 'PhabricatorConduitDAO',
|
|
|
|
'PhabricatorConduitConsoleController' => 'PhabricatorConduitController',
|
|
|
|
'PhabricatorConduitController' => 'PhabricatorController',
|
|
|
|
'PhabricatorConduitDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorConduitLogController' => 'PhabricatorConduitController',
|
|
|
|
'PhabricatorConduitMethodCallLog' => 'PhabricatorConduitDAO',
|
2011-06-14 21:17:14 +02:00
|
|
|
'PhabricatorConduitTokenController' => 'PhabricatorConduitController',
|
Track content sources (email, web, conduit, mobile) for replies
Summary:
When an object is updated, record the content source for the update. This mostly
isn't terribly useful but one concrete thing I want to do with it is let admins
audit via-email replies more easily since there are a bunch of options which let
you do hyjinx if you intentionally configure them insecurely. I think having a
little more auditability around this feature is generally good. At some point
I'm going to turn this into a link admins can click to see details.
It also allows us to see how frequently different mechanisms are used, and lets
you see if someone is at their desk or on a mobile or whatever, at least
indirectly.
The "tablet" and "mobile" sources are currently unused but I figured I'd throw
them in anyway. SMS support should definitely happen at some point.
Not 100% sure about the design for this, I might change it to plain text at some
point.
Test Plan: Updated objects and saw update sources rendered.
Reviewers: jungejason, tuomaspelkonen, aran
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Differential Revision: 844
2011-08-22 19:25:45 +02:00
|
|
|
'PhabricatorContentSourceView' => 'AphrontView',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorController' => 'AphrontController',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorCountdownController' => 'PhabricatorController',
|
|
|
|
'PhabricatorCountdownDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorCountdownDeleteController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownEditController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownListController' => 'PhabricatorCountdownController',
|
|
|
|
'PhabricatorCountdownViewController' => 'PhabricatorCountdownController',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorDaemon' => 'PhutilDaemon',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonCombinedLogController' => 'PhabricatorDaemonController',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorDaemonConsoleController' => 'PhabricatorDaemonController',
|
|
|
|
'PhabricatorDaemonController' => 'PhabricatorController',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorDaemonLog' => 'PhabricatorDaemonDAO',
|
|
|
|
'PhabricatorDaemonLogEvent' => 'PhabricatorDaemonDAO',
|
2011-05-03 02:05:22 +02:00
|
|
|
'PhabricatorDaemonLogEventsView' => 'AphrontView',
|
|
|
|
'PhabricatorDaemonLogListController' => 'PhabricatorDaemonController',
|
|
|
|
'PhabricatorDaemonLogListView' => 'AphrontView',
|
2011-03-15 21:38:14 +01:00
|
|
|
'PhabricatorDaemonLogViewController' => 'PhabricatorDaemonController',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorDaemonTimelineConsoleController' => 'PhabricatorDaemonController',
|
|
|
|
'PhabricatorDaemonTimelineEventController' => 'PhabricatorDaemonController',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorDefaultFileStorageEngineSelector' => 'PhabricatorFileStorageEngineSelector',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorDefaultSearchEngineSelector' => 'PhabricatorSearchEngineSelector',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryCategory' => 'PhabricatorDirectoryDAO',
|
|
|
|
'PhabricatorDirectoryCategoryDeleteController' => 'PhabricatorDirectoryController',
|
|
|
|
'PhabricatorDirectoryCategoryEditController' => 'PhabricatorDirectoryController',
|
Replace home directory list with a dashboard
Summary:
Rough cut that still needs a lot of polish, but replace the directory list with
more of a dashboard type thing:
- Show "Unbreak Now", triage-in-your-projects, and other stuff that you're
supposed to deal with, then feed.
- Move tools a click a way behind nav -- this also lets us put more stuff
there and subtools, etc., later.
- Remove tabs.
- Merge the category/item editing views.
- I also added a light blue wash to the side nav, not sure if I like that or
not.
Test Plan:
- Viewed all elements in empty and nonempty states.
- Viewed applications, edited items/categories.
Reviewers: btrahan, aran
Reviewed By: btrahan
CC: aran, epriestley, davidreuss
Maniphest Tasks: T21, T631
Differential Revision: https://secure.phabricator.com/D1574
2012-02-08 01:04:48 +01:00
|
|
|
'PhabricatorDirectoryCategoryViewController' => 'PhabricatorDirectoryController',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryController' => 'PhabricatorController',
|
|
|
|
'PhabricatorDirectoryDAO' => 'PhabricatorLiskDAO',
|
Replace home directory list with a dashboard
Summary:
Rough cut that still needs a lot of polish, but replace the directory list with
more of a dashboard type thing:
- Show "Unbreak Now", triage-in-your-projects, and other stuff that you're
supposed to deal with, then feed.
- Move tools a click a way behind nav -- this also lets us put more stuff
there and subtools, etc., later.
- Remove tabs.
- Merge the category/item editing views.
- I also added a light blue wash to the side nav, not sure if I like that or
not.
Test Plan:
- Viewed all elements in empty and nonempty states.
- Viewed applications, edited items/categories.
Reviewers: btrahan, aran
Reviewed By: btrahan
CC: aran, epriestley, davidreuss
Maniphest Tasks: T21, T631
Differential Revision: https://secure.phabricator.com/D1574
2012-02-08 01:04:48 +01:00
|
|
|
'PhabricatorDirectoryEditController' => 'PhabricatorDirectoryController',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorDirectoryItem' => 'PhabricatorDirectoryDAO',
|
|
|
|
'PhabricatorDirectoryItemDeleteController' => 'PhabricatorDirectoryController',
|
|
|
|
'PhabricatorDirectoryItemEditController' => 'PhabricatorDirectoryController',
|
|
|
|
'PhabricatorDirectoryMainController' => 'PhabricatorDirectoryController',
|
2011-05-12 19:06:54 +02:00
|
|
|
'PhabricatorDisabledUserController' => 'PhabricatorAuthController',
|
2011-02-06 01:57:21 +01:00
|
|
|
'PhabricatorDraft' => 'PhabricatorDraftDAO',
|
|
|
|
'PhabricatorDraftDAO' => 'PhabricatorLiskDAO',
|
Add an assocations-like "Edges" framework
Summary:
We have a lot of cases where we store object relationships, but it's all kind of messy and custom. Some particular problems:
- We go to great lengths to enforce order stability in Differential revisions, but the implementation is complex and inelegant.
- Some relationships are stored on-object, so we can't pull the inverses easily. For example, Maniphest shows child tasks but not parent tasks.
- I want to add more of these and don't want to continue building custom stuff.
- UIs like the "attach stuff to other stuff" UI need custom branches for each object type.
- Stuff like "allow commits to close tasks" is notrivial because of nonstandard metadata storage.
Provide an association-like "edge" framework to fix these problems. This is nearly identical to associations, with a few differences:
- I put edge metadata in a separate table and don't load it by default, to keep edge rows small and allow large metadata if necessary. The on-edge metadata seemed to get abused a lot at Facebook.
- I put a 'seq' column on the edges to ensure they have an explicit, stable ordering within a source and type.
This isn't actually used anywhere yet, but my first target is attaching commits to tasks for T904.
Test Plan: Made a mock page that used Editor and Query. Verified adding and removing edges, overwriting edges, writing and loading edge data, sequence number generation.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran, 20after4
Differential Revision: https://secure.phabricator.com/D2088
2012-04-05 00:30:21 +02:00
|
|
|
'PhabricatorEdgeConfig' => 'PhabricatorEdgeConstants',
|
|
|
|
'PhabricatorEdgeQuery' => 'PhabricatorQuery',
|
2011-01-31 20:55:26 +01:00
|
|
|
'PhabricatorEmailLoginController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorEmailTokenController' => 'PhabricatorAuthController',
|
2012-01-12 01:07:36 +01:00
|
|
|
'PhabricatorEnvTestCase' => 'PhabricatorTestCase',
|
2012-04-08 02:25:31 +02:00
|
|
|
'PhabricatorErrorExample' => 'PhabricatorUIExample',
|
2011-11-10 02:23:33 +01:00
|
|
|
'PhabricatorEvent' => 'PhutilEvent',
|
|
|
|
'PhabricatorEventType' => 'PhutilEventType',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFeedDAO' => 'PhabricatorLiskDAO',
|
2011-07-10 03:03:59 +02:00
|
|
|
'PhabricatorFeedPublicStreamController' => 'PhabricatorFeedController',
|
2012-02-27 18:49:01 +01:00
|
|
|
'PhabricatorFeedStoryAudit' => 'PhabricatorFeedStory',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryData' => 'PhabricatorFeedDAO',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryDifferential' => 'PhabricatorFeedStory',
|
2011-12-17 22:27:11 +01:00
|
|
|
'PhabricatorFeedStoryManiphest' => 'PhabricatorFeedStory',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhabricatorFeedStoryPhriction' => 'PhabricatorFeedStory',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorFeedStoryProject' => 'PhabricatorFeedStory',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryReference' => 'PhabricatorFeedDAO',
|
2011-07-09 22:28:09 +02:00
|
|
|
'PhabricatorFeedStoryStatus' => 'PhabricatorFeedStory',
|
2011-07-10 00:44:49 +02:00
|
|
|
'PhabricatorFeedStoryTypeConstants' => 'PhabricatorFeedConstants',
|
2011-07-05 17:35:18 +02:00
|
|
|
'PhabricatorFeedStoryUnknown' => 'PhabricatorFeedStory',
|
|
|
|
'PhabricatorFeedStoryView' => 'PhabricatorFeedView',
|
|
|
|
'PhabricatorFeedView' => 'AphrontView',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFile' => 'PhabricatorFileDAO',
|
|
|
|
'PhabricatorFileController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFileDAO' => 'PhabricatorLiskDAO',
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
'PhabricatorFileDataController' => 'PhabricatorFileController',
|
2012-01-16 22:26:44 +01:00
|
|
|
'PhabricatorFileDeleteController' => 'PhabricatorFileController',
|
2011-05-22 20:55:10 +02:00
|
|
|
'PhabricatorFileDropUploadController' => 'PhabricatorFileController',
|
2011-04-14 00:15:48 +02:00
|
|
|
'PhabricatorFileImageMacro' => 'PhabricatorFileDAO',
|
Move ALL files to serve from the alternate file domain, not just files without
"Content-Disposition: attachment"
Summary:
We currently serve some files off the primary domain (with "Content-Disposition:
attachment" + a CSRF check) and some files off the alternate domain (without
either).
This is not sufficient, because some UAs (like the iPad) ignore
"Content-Disposition: attachment". So there's an attack that goes like this:
- Alice uploads xss.html
- Alice says to Bob "hey download this file on your iPad"
- Bob clicks "Download" on Phabricator on his iPad, gets XSS'd.
NOTE: This removes the CSRF check for downloading files. The check is nice to
have but only raises the barrier to entry slightly. Between iPad / sniffing /
flash bytecode attacks, single-domain installs are simply insecure. We could
restore the check at some point in conjunction with a derived authentication
cookie (i.e., a mini-session-token which is only useful for downloading files),
but that's a lot of complexity to drop all at once.
(Because files are now authenticated only by knowing the PHID and secret key,
this also fixes the "no profile pictures in public feed while logged out"
issue.)
Test Plan: Viewed, info'd, and downloaded files
Reviewers: btrahan, arice, alok
Reviewed By: arice
CC: aran, epriestley
Maniphest Tasks: T843
Differential Revision: https://secure.phabricator.com/D1608
2012-02-14 23:52:27 +01:00
|
|
|
'PhabricatorFileInfoController' => 'PhabricatorFileController',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileListController' => 'PhabricatorFileController',
|
2011-05-03 19:45:45 +02:00
|
|
|
'PhabricatorFileMacroDeleteController' => 'PhabricatorFileController',
|
|
|
|
'PhabricatorFileMacroEditController' => 'PhabricatorFileController',
|
|
|
|
'PhabricatorFileMacroListController' => 'PhabricatorFileController',
|
2011-05-02 23:20:24 +02:00
|
|
|
'PhabricatorFileProxyController' => 'PhabricatorFileController',
|
|
|
|
'PhabricatorFileProxyImage' => 'PhabricatorFileDAO',
|
2011-12-15 07:37:23 +01:00
|
|
|
'PhabricatorFileSideNavView' => 'AphrontView',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileStorageBlob' => 'PhabricatorFileDAO',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorFileTransformController' => 'PhabricatorFileController',
|
2011-01-23 03:33:00 +01:00
|
|
|
'PhabricatorFileUploadController' => 'PhabricatorFileController',
|
2011-12-15 07:37:23 +01:00
|
|
|
'PhabricatorFileUploadView' => 'AphrontView',
|
2012-03-28 01:22:40 +02:00
|
|
|
'PhabricatorFlag' => 'PhabricatorFlagDAO',
|
|
|
|
'PhabricatorFlagColor' => 'PhabricatorFlagConstants',
|
|
|
|
'PhabricatorFlagController' => 'PhabricatorController',
|
|
|
|
'PhabricatorFlagDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorFlagDeleteController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagEditController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagListController' => 'PhabricatorFlagController',
|
|
|
|
'PhabricatorFlagListView' => 'AphrontView',
|
2012-04-04 21:14:10 +02:00
|
|
|
'PhabricatorFormExample' => 'PhabricatorUIExample',
|
2011-07-03 18:47:31 +02:00
|
|
|
'PhabricatorGarbageCollectorDaemon' => 'PhabricatorDaemon',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorGoodForNothingWorker' => 'PhabricatorWorker',
|
2011-05-28 20:36:00 +02:00
|
|
|
'PhabricatorHelpController' => 'PhabricatorController',
|
|
|
|
'PhabricatorHelpKeyboardShortcutController' => 'PhabricatorHelpController',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorIDPagedPolicyQuery' => 'PhabricatorPolicyQuery',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCBot' => 'PhabricatorDaemon',
|
2012-01-06 20:31:00 +01:00
|
|
|
'PhabricatorIRCDifferentialNotificationHandler' => 'PhabricatorIRCHandler',
|
2012-02-17 19:21:38 +01:00
|
|
|
'PhabricatorIRCLogHandler' => 'PhabricatorIRCHandler',
|
2012-03-09 21:40:03 +01:00
|
|
|
'PhabricatorIRCMacroHandler' => 'PhabricatorIRCHandler',
|
2011-05-17 23:40:25 +02:00
|
|
|
'PhabricatorIRCObjectNameHandler' => 'PhabricatorIRCHandler',
|
2011-05-15 18:29:48 +02:00
|
|
|
'PhabricatorIRCProtocolHandler' => 'PhabricatorIRCHandler',
|
2012-02-24 03:01:25 +01:00
|
|
|
'PhabricatorIRCWhatsNewHandler' => 'PhabricatorIRCHandler',
|
2011-10-20 03:26:21 +02:00
|
|
|
'PhabricatorInfrastructureTestCase' => 'PhabricatorTestCase',
|
Add inline comments to Diffusion/Audit
Summary:
- Add inline comments to Audits, like Differential.
- Creates new storage for the comments in the Audits database.
- Creates a new PhabricatorAuditInlineComment class, similar to DifferentialInlineComment.
- Defines an Interface which Differential and Audit comments conform to.
- Makes consumers of DifferentialInlineComments consume objects which implement that interface instead.
- Adds save
NOTE: Some features are still missing! Wanted to cut this off before it got crazy:
- Inline comments aren't shown in the main comment list.
- Inline comments aren't shown in the emails.
- Inline comments aren't previewed.
I'll followup with those but this was getting pretty big.
@vrana, does the SQL change look correct?
Test Plan:
- Created, edited, deleted, replied to, reloaded and saved inline comments in Diffusion, on the left and right side of diffs.
- Created, edited, deleted, replied to, reloaded and saved inline comments in Differentila, on the left and right side of primary and diff-versus-diff diffs.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: aran, epriestley
Maniphest Tasks: T904
Differential Revision: https://secure.phabricator.com/D1898
2012-03-14 20:56:01 +01:00
|
|
|
'PhabricatorInlineCommentController' => 'PhabricatorController',
|
2012-03-20 03:45:16 +01:00
|
|
|
'PhabricatorInlineSummaryView' => 'AphrontView',
|
Bring Javelin into Phabricator via git submodule, not copy-and-paste
Summary:
Javelin is currently embedded in Phabricator via copy-and-paste of prebuilt
packages. This is not so great.
Pull it in as a submodule instead and make all the Phabriator resources declare
proper dependency trees. Add Javelin linting.
Test Plan:
I tried to run through pretty much all the JS functionality on the site. This is
still a high-risk change, but I did a pretty thorough test
Differential: inline comments, revealing diffs, list tokenizers, comment
preview, editing/deleting comments, add review action.
Maniphest: list tokenizer, comment actions
Herald: rule editing, tokenizers, add/remove rows
Reviewed By: tomo
Reviewers: aran, tomo, mroch, jungejason, tuomaspelkonen
CC: aran, tomo, epriestley
Differential Revision: 223
2011-05-04 00:11:55 +02:00
|
|
|
'PhabricatorJavelinLinter' => 'ArcanistLinter',
|
|
|
|
'PhabricatorLintEngine' => 'PhutilLintEngine',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorLiskDAO' => 'LiskDAO',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorLocalDiskFileStorageEngine' => 'PhabricatorFileStorageEngine',
|
Improve time localization code
Summary:
- We throw on a missing date right now, in the DateTime constructor. This can
happen in reasonable cases and this is display code, so handle it more
gracefully (see T520).
- This stuff is a little slow and we sometimes render many hundreds of dates
per page. I've been seeing it in profiles on and off. Memoize timezones to
improve performance.
- Some minor code duplication that would have become less-minor with the
constructor change, consolidate the logic.
- Add some unit tests and a little documentation.
Test Plan:
- Ran unit tests.
- Profiled 1,000 calls to phabricator_datetime(), cost dropped from ~49ms to
~19ms with addition of memoization. This is still slower than I'd like but I
don't think there's an easy way to squeeze it down further.
Reviewers: ajtrichards, jungejason, nh, tuomaspelkonen, aran
Reviewed By: ajtrichards
CC: aran, ajtrichards, epriestley
Differential Revision: 966
2011-09-27 18:03:55 +02:00
|
|
|
'PhabricatorLocalTimeTestCase' => 'PhabricatorTestCase',
|
2011-01-26 22:21:12 +01:00
|
|
|
'PhabricatorLoginController' => 'PhabricatorAuthController',
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
'PhabricatorLoginValidateController' => 'PhabricatorAuthController',
|
2011-01-31 03:52:29 +01:00
|
|
|
'PhabricatorLogoutController' => 'PhabricatorAuthController',
|
2011-02-10 02:39:55 +01:00
|
|
|
'PhabricatorMailImplementationAmazonSESAdapter' => 'PhabricatorMailImplementationPHPMailerLiteAdapter',
|
2011-01-26 18:33:31 +01:00
|
|
|
'PhabricatorMailImplementationPHPMailerLiteAdapter' => 'PhabricatorMailImplementationAdapter',
|
2011-05-26 19:00:26 +02:00
|
|
|
'PhabricatorMailImplementationSendGridAdapter' => 'PhabricatorMailImplementationAdapter',
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 20:47:00 +02:00
|
|
|
'PhabricatorMailImplementationTestAdapter' => 'PhabricatorMailImplementationAdapter',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAController' => 'PhabricatorController',
|
|
|
|
'PhabricatorMetaMTADAO' => 'PhabricatorLiskDAO',
|
2011-06-01 17:33:14 +02:00
|
|
|
'PhabricatorMetaMTAEmailBodyParserTestCase' => 'PhabricatorTestCase',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTAListController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAMail' => 'PhabricatorMetaMTADAO',
|
Fix a threading issue with Amazon SES
Summary:
Amazon SES does not allow us to set a Message-ID header, which means
that threads are incorrect in Mail.app (and presumably other applications
which respect In-Reply-To and References) because the initial email does not
have anything which attaches it to the rest of the thread. To fix this, never
rely on Message-ID if the mailer doesn't support Message-ID.
(In the Amazon SES case, Amazon generates its own Message-ID which we can't
know ahead of time).
I additionally used all the Lisk isolation from the other tests to make this
testable and wrote tests for it.
I also moved the idea of a thread ID lower in the stack and out of
DifferentialMail, which should not be responsible for implementation details.
NOTE: If you push this, it will cause a one-time break of threading for
everyone using Outlook since I've changed the seed for generating Thread-Index.
I feel like this is okay to avoid introducing more complexity here.
Test Plan:
Created and then updated a revision, messages delivered over Amazon
SES threaded correctly in Mail.app. Verified headers. Unit tests.
Reviewed By: rm
Reviewers: aran, tuomaspelkonen, jungejason, rm
Commenters: aran
CC: aran, rm, epriestley
Differential Revision: 195
2011-04-30 20:47:00 +02:00
|
|
|
'PhabricatorMetaMTAMailTestCase' => 'PhabricatorTestCase',
|
2011-01-26 19:40:38 +01:00
|
|
|
'PhabricatorMetaMTAMailingList' => 'PhabricatorMetaMTADAO',
|
|
|
|
'PhabricatorMetaMTAMailingListEditController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAMailingListsController' => 'PhabricatorMetaMTAController',
|
2011-05-05 08:09:42 +02:00
|
|
|
'PhabricatorMetaMTAReceiveController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAReceivedListController' => 'PhabricatorMetaMTAController',
|
|
|
|
'PhabricatorMetaMTAReceivedMail' => 'PhabricatorMetaMTADAO',
|
2011-01-26 02:40:21 +01:00
|
|
|
'PhabricatorMetaMTASendController' => 'PhabricatorMetaMTAController',
|
2011-05-30 20:07:05 +02:00
|
|
|
'PhabricatorMetaMTASendGridReceiveController' => 'PhabricatorMetaMTAController',
|
2011-01-26 18:08:26 +01:00
|
|
|
'PhabricatorMetaMTAViewController' => 'PhabricatorMetaMTAController',
|
2012-02-28 02:11:25 +01:00
|
|
|
'PhabricatorMetaMTAWorker' => 'PhabricatorWorker',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorMySQLFileStorageEngine' => 'PhabricatorFileStorageEngine',
|
2012-03-07 05:14:03 +01:00
|
|
|
'PhabricatorNotificationsController' => 'PhabricatorController',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthClientAuthorization' => 'PhabricatorOAuthServerDAO',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientAuthorizationBaseController' => 'PhabricatorOAuthServerController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationDeleteController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationEditController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
|
|
|
'PhabricatorOAuthClientAuthorizationListController' => 'PhabricatorOAuthClientAuthorizationBaseController',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthClientAuthorizationQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthClientBaseController' => 'PhabricatorOAuthServerController',
|
|
|
|
'PhabricatorOAuthClientDeleteController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientEditController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientListController' => 'PhabricatorOAuthClientBaseController',
|
|
|
|
'PhabricatorOAuthClientViewController' => 'PhabricatorOAuthClientBaseController',
|
2011-02-28 04:47:22 +01:00
|
|
|
'PhabricatorOAuthDefaultRegistrationController' => 'PhabricatorOAuthRegistrationController',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorOAuthDiagnosticsController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorOAuthFailureView' => 'AphrontView',
|
|
|
|
'PhabricatorOAuthLoginController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorOAuthProviderFacebook' => 'PhabricatorOAuthProvider',
|
2012-02-03 02:25:31 +01:00
|
|
|
'PhabricatorOAuthProviderGitHub' => 'PhabricatorOAuthProvider',
|
Add Google as an OAuth2 provider (BETA)
Summary:
This is pretty straightforward, except:
- We need to request read/write access to the address book to get the account
ID (which we MUST have) and real name, email and account name (which we'd like
to have). This is way more access than we should need, but there's apparently no
"get_loggedin_user_basic_information" type of call in the Google API suite (or,
at least, I couldn't find one).
- We can't get the profile picture or profile URI since there's no Plus API
access and Google users don't have meaningful public pages otherwise.
- Google doesn't save the fact that you've authorized the app, so every time
you want to login you need to reaffirm that you want to give us silly amounts of
access. Phabricator sessions are pretty long-duration though so this shouldn't
be a major issue.
Test Plan:
- Registered, logged out, and logged in with Google.
- Registered, logged out, and logged in with Facebook / Github to make sure I
didn't break anything.
- Linked / unlinked Google accounts.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: aran
CC: aran, epriestley, Makinde
Differential Revision: 916
2011-09-09 01:37:22 +02:00
|
|
|
'PhabricatorOAuthProviderGoogle' => 'PhabricatorOAuthProvider',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthProviderPhabricator' => 'PhabricatorOAuthProvider',
|
2011-02-28 04:47:22 +01:00
|
|
|
'PhabricatorOAuthRegistrationController' => 'PhabricatorAuthController',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthResponse' => 'AphrontResponse',
|
|
|
|
'PhabricatorOAuthServerAccessToken' => 'PhabricatorOAuthServerDAO',
|
|
|
|
'PhabricatorOAuthServerAuthController' => 'PhabricatorAuthController',
|
|
|
|
'PhabricatorOAuthServerAuthorizationCode' => 'PhabricatorOAuthServerDAO',
|
|
|
|
'PhabricatorOAuthServerClient' => 'PhabricatorOAuthServerDAO',
|
2012-04-05 02:51:16 +02:00
|
|
|
'PhabricatorOAuthServerClientQuery' => 'PhabricatorOffsetPagedQuery',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthServerController' => 'PhabricatorController',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthServerDAO' => 'PhabricatorLiskDAO',
|
OAuthServer polish and random sauce
Summary:
This diff makes the OAuthServer more compliant with the spec by
- making it return well-formatted error codes with error types from the spec.
- making it respect the "state" variable, which is a transparent variable the
client passes and the server passes back
- making it be super, duper compliant with respect to redirect uris
-- if specified in authorization step, check if its valid relative to the client
registered URI and if so save it
-- if specified in authorization step, check if its been specified in the access
step and error if it doesn't match or doesn't exist
-- note we don't make any use of it in the access step which seems strange but
hey, that's what the spec says!
This diff makes the OAuthServer suck less by
- making the "cancel" button do something in the user authorization flow
- making the client list view and client edit view be a bit more usable around
client secrets
- fixing a few bugs I managed to introduce along the way
Test Plan:
- create a test phabricator client, updated my conf, and then linked and
unlinked phabricator to itself
- wrote some tests for PhabricatorOAuthServer -- they pass!
-- these validate the various validate URI checks
- tried a few important authorization calls
--
http://phabricator.dev/oauthserver/auth/?client_id=X&state=test&redirect_uri=http://www.evil.com
--- verified error'd from mismatching redirect uri's
--- verified state parameter in response
--- verified did not redirect to client redirect uri
-- http://phabricator.dev/oauthserver/auth/?client_id=X w/ existing
authorization
--- got redirected to proper client url with error that response_type not
specified
-- http://phabricator.dev/oauthserver/auth/?client_id=X&response_type=code w/
existing authorization
--- got redirected to proper client url with pertinent code!
- tried a few important access calls
-- verified appropriate errors if missing any required parameters
-- verified good access code with appropriate other variables resulted in an
access token
- verified that if redirect_uri set correctly in authorization required for
access and errors if differs at all / only succeeds if exactly the same
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley, ajtrichards
Maniphest Tasks: T889, T906, T897
Differential Revision: https://secure.phabricator.com/D1727
2012-03-01 23:46:18 +01:00
|
|
|
'PhabricatorOAuthServerTestCase' => 'PhabricatorTestCase',
|
2012-02-22 19:21:39 +01:00
|
|
|
'PhabricatorOAuthServerTestController' => 'PhabricatorOAuthServerController',
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'PhabricatorOAuthServerTokenController' => 'PhabricatorAuthController',
|
2011-02-22 07:51:34 +01:00
|
|
|
'PhabricatorOAuthUnlinkController' => 'PhabricatorAuthController',
|
2011-07-05 22:18:47 +02:00
|
|
|
'PhabricatorObjectGraph' => 'AbstractDirectedGraph',
|
Add object status to Handles
Summary:
We use ObjectHandles as proxy objects which can refer to any other object in the
system. Add the concept of the underlying object's "status" (e.g., open, closed
or busy).
This allows us to render completed tasks and revisions with strikethrough. In
the future, if we implement OOO or something, we could render users with a
"busy" status if they're on vacation, etc.
Test Plan: Viewed a task with closed revisions and dependencies:
https://secure.phabricator.com/file/view/PHID-FILE-6183e81286fa3288d33d/
Reviewed By: codeblock
Reviewers: codeblock, hunterbridges, jungejason, tuomaspelkonen, aran
CC: aran, codeblock
Differential Revision: 772
2011-08-03 15:37:18 +02:00
|
|
|
'PhabricatorObjectHandleStatus' => 'PhabricatorObjectHandleConstants',
|
2012-03-27 05:54:26 +02:00
|
|
|
'PhabricatorOffsetPagedQuery' => 'PhabricatorQuery',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersController' => 'PhabricatorController',
|
|
|
|
'PhabricatorOwnersDAO' => 'PhabricatorLiskDAO',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersDeleteController' => 'PhabricatorOwnersController',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersDetailController' => 'PhabricatorOwnersController',
|
2011-04-04 07:03:27 +02:00
|
|
|
'PhabricatorOwnersEditController' => 'PhabricatorOwnersController',
|
2011-04-03 23:48:36 +02:00
|
|
|
'PhabricatorOwnersListController' => 'PhabricatorOwnersController',
|
|
|
|
'PhabricatorOwnersOwner' => 'PhabricatorOwnersDAO',
|
|
|
|
'PhabricatorOwnersPackage' => 'PhabricatorOwnersDAO',
|
|
|
|
'PhabricatorOwnersPath' => 'PhabricatorOwnersDAO',
|
2011-01-23 06:09:13 +01:00
|
|
|
'PhabricatorPHID' => 'PhabricatorPHIDDAO',
|
|
|
|
'PhabricatorPHIDController' => 'PhabricatorController',
|
|
|
|
'PhabricatorPHIDDAO' => 'PhabricatorLiskDAO',
|
2011-01-26 18:02:09 +01:00
|
|
|
'PhabricatorPHIDLookupController' => 'PhabricatorPHIDController',
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPaste' => 'PhabricatorPasteDAO',
|
|
|
|
'PhabricatorPasteController' => 'PhabricatorController',
|
|
|
|
'PhabricatorPasteDAO' => 'PhabricatorLiskDAO',
|
2011-06-14 04:12:30 +02:00
|
|
|
'PhabricatorPasteListController' => 'PhabricatorPasteController',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorPasteQuery' => 'PhabricatorIDPagedPolicyQuery',
|
2011-06-10 08:53:53 +02:00
|
|
|
'PhabricatorPasteViewController' => 'PhabricatorPasteController',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleController' => 'PhabricatorController',
|
|
|
|
'PhabricatorPeopleEditController' => 'PhabricatorPeopleController',
|
|
|
|
'PhabricatorPeopleListController' => 'PhabricatorPeopleController',
|
Provide an activity log for login and administrative actions
Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish.
Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen:
- The log itself is useful if there are shenanigans.
- Password login can check it and start CAPTCHA'ing users after a few failed attempts.
I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow.
Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways.
Reviewers: jungejason, tuomaspelkonen, aran
CC:
Differential Revision: 302
2011-05-18 03:42:21 +02:00
|
|
|
'PhabricatorPeopleLogsController' => 'PhabricatorPeopleController',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorPeopleProfileController' => 'PhabricatorPeopleController',
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorPolicies' => 'PhabricatorPolicyConstants',
|
|
|
|
'PhabricatorPolicyCapability' => 'PhabricatorPolicyConstants',
|
|
|
|
'PhabricatorPolicyQuery' => 'PhabricatorQuery',
|
|
|
|
'PhabricatorPolicyTestCase' => 'PhabricatorTestCase',
|
|
|
|
'PhabricatorPolicyTestQuery' => 'PhabricatorPolicyQuery',
|
2011-12-17 05:01:38 +01:00
|
|
|
'PhabricatorProfileHeaderView' => 'AphrontView',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProject' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectAffiliation' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectController' => 'PhabricatorController',
|
2011-06-26 17:37:47 +02:00
|
|
|
'PhabricatorProjectCreateController' => 'PhabricatorProjectController',
|
2011-02-21 03:41:23 +01:00
|
|
|
'PhabricatorProjectDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorProjectListController' => 'PhabricatorProjectController',
|
|
|
|
'PhabricatorProjectProfile' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectProfileController' => 'PhabricatorProjectController',
|
2011-06-18 10:13:56 +02:00
|
|
|
'PhabricatorProjectProfileEditController' => 'PhabricatorProjectController',
|
2011-07-20 07:48:38 +02:00
|
|
|
'PhabricatorProjectSubproject' => 'PhabricatorProjectDAO',
|
2012-01-24 16:11:37 +01:00
|
|
|
'PhabricatorProjectTransaction' => 'PhabricatorProjectDAO',
|
|
|
|
'PhabricatorProjectTransactionType' => 'PhabricatorProjectConstants',
|
2012-01-25 20:51:20 +01:00
|
|
|
'PhabricatorProjectUpdateController' => 'PhabricatorProjectController',
|
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',
|
2011-05-31 19:23:31 +02:00
|
|
|
'PhabricatorRemarkupRuleDifferential' => 'PhabricatorRemarkupRuleObjectName',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleDifferentialHandle' => 'PhabricatorRemarkupRuleObjectHandle',
|
2011-04-11 12:02:19 +02:00
|
|
|
'PhabricatorRemarkupRuleDiffusion' => 'PhutilRemarkupRule',
|
2011-07-15 23:17:55 +02:00
|
|
|
'PhabricatorRemarkupRuleEmbedFile' => 'PhutilRemarkupRule',
|
2011-04-14 00:15:48 +02:00
|
|
|
'PhabricatorRemarkupRuleImageMacro' => 'PhutilRemarkupRule',
|
2011-05-31 19:23:31 +02:00
|
|
|
'PhabricatorRemarkupRuleManiphest' => 'PhabricatorRemarkupRuleObjectName',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleManiphestHandle' => 'PhabricatorRemarkupRuleObjectHandle',
|
2011-06-24 19:59:57 +02:00
|
|
|
'PhabricatorRemarkupRuleMention' => 'PhutilRemarkupRule',
|
Provide a "reference-with-full-name" syntax for Remarkup
Summary:
Provide a {T123} syntax which pulls in the entire name of an object, not just a
link to it. A major use for this is organizing projects using wiki pages. Since
handle links show object status now, this lets you organize stuff in an ad-hoc
way and get a reasonable overview of it. We can make handles richer in the
future, too.
The performance on this isn't perfect (it adds some potential single gets) but I
think it's okay for now and I don't want to make remarkup engine even more
complex until the preprocess/postprocess stuff has had a chance to settle and
I'm more confident it works.
In Differential and Maniphest we'll also incorrectly cache the object
state/name, but that'll fix itself once I move the cache code to use
preprocess/postprocess correctly.
Test Plan:
- See https://secure.phabricator.com/file/view/PHID-FILE-5f9ca32407bec20899b9/
for an example.
- Generated and looked over the documentation.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, hunterbridges
CC: skrul, aran, jungejason, epriestley
Differential Revision: 784
2011-08-05 17:50:26 +02:00
|
|
|
'PhabricatorRemarkupRuleObjectHandle' => 'PhutilRemarkupRule',
|
2011-05-31 19:23:31 +02:00
|
|
|
'PhabricatorRemarkupRuleObjectName' => 'PhutilRemarkupRule',
|
2011-06-27 08:57:43 +02:00
|
|
|
'PhabricatorRemarkupRulePaste' => 'PhabricatorRemarkupRuleObjectName',
|
2011-07-12 05:14:46 +02:00
|
|
|
'PhabricatorRemarkupRulePhriction' => 'PhutilRemarkupRule',
|
2011-05-02 23:20:24 +02:00
|
|
|
'PhabricatorRemarkupRuleProxyImage' => 'PhutilRemarkupRule',
|
2011-05-27 21:50:02 +02:00
|
|
|
'PhabricatorRemarkupRuleYoutube' => 'PhutilRemarkupRule',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepository' => 'PhabricatorRepositoryDAO',
|
2011-04-06 05:49:31 +02:00
|
|
|
'PhabricatorRepositoryArcanistProject' => 'PhabricatorRepositoryDAO',
|
|
|
|
'PhabricatorRepositoryArcanistProjectEditController' => 'PhabricatorRepositoryController',
|
Migrate "PhabricatorOwnersPackageCommitRelationship" to "PhabricatorRepositoryAuditRequest"
Summary:
- Move table to Repository, since we have no Owners joins in the application anymore but would like to do a Repository join.
- Rename "packagePHID" to "auditorPHID", since this column may contain package, project, or user PHIDs.
Test Plan:
- Browsed Owners, Audit, and Differential interfaces to the Audit tool.
- Made comments and state changes.
- Ran "reparse.php --herald --owners" on several commits.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, epriestley, nh, vrana
Maniphest Tasks: T904
Differential Revision: https://secure.phabricator.com/D1787
2012-03-05 22:17:29 +01:00
|
|
|
'PhabricatorRepositoryAuditRequest' => 'PhabricatorRepositoryDAO',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryCommit' => 'PhabricatorRepositoryDAO',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitChangeParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
|
|
|
'PhabricatorRepositoryCommitData' => 'PhabricatorRepositoryDAO',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryCommitDiscoveryDaemon' => 'PhabricatorRepositoryDaemon',
|
2011-04-04 08:23:36 +02:00
|
|
|
'PhabricatorRepositoryCommitHeraldWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitMessageParserWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
Add Related Commits for Owners
Summary:
For each commit, find the affected packages, and provide a way to
search by package.
Test Plan:
create commits that touch and don't touch two packages, and verify
that they display correctly in all the UI pages.
Reviewers: epriestley, blair, nh, tuomaspelkonen
Reviewed By: epriestley
CC: benmathews, aran, epriestley, btrahan, jungejason, mpodobnik, prithvi
Maniphest Tasks: T83
Differential Revision: 1208
2011-12-14 09:53:25 +01:00
|
|
|
'PhabricatorRepositoryCommitOwnersWorker' => 'PhabricatorRepositoryCommitParserWorker',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryCommitParserWorker' => 'PhabricatorWorker',
|
|
|
|
'PhabricatorRepositoryCommitTaskDaemon' => 'PhabricatorRepositoryDaemon',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryController' => 'PhabricatorController',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryCreateController' => 'PhabricatorRepositoryController',
|
2011-02-13 03:26:15 +01:00
|
|
|
'PhabricatorRepositoryDAO' => 'PhabricatorLiskDAO',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryDaemon' => 'PhabricatorDaemon',
|
2011-04-02 02:11:05 +02:00
|
|
|
'PhabricatorRepositoryDefaultCommitMessageDetailParser' => 'PhabricatorRepositoryCommitMessageDetailParser',
|
2011-05-05 21:53:39 +02:00
|
|
|
'PhabricatorRepositoryDeleteController' => 'PhabricatorRepositoryController',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryEditController' => 'PhabricatorRepositoryController',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
|
2011-12-23 17:11:11 +01:00
|
|
|
'PhabricatorRepositoryGitCommitDiscoveryDaemonTestCase' => 'PhabricatorTestCase',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositoryGitCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
|
2011-08-09 21:47:46 +02:00
|
|
|
'PhabricatorRepositoryGitFetchDaemon' => 'PhabricatorRepositoryPullLocalDaemon',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositoryListController' => 'PhabricatorRepositoryController',
|
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 commit discovery daemon
Summary:
Repository import has three major steps:
- Commit discovery (serial)
- Message parsing (parallel, mostly VCS independent)
- Change parsing (parallel, highly VCS dependent)
This implements commit discovery for Mercurial, similar to git's parsing:
- List the heads of all the branches.
- If we haven't already discovered them, follow them back to their roots (or
the first commit we have discovered).
- Import all the newly discovered commits, oldest first.
This is a little complicated but it ensures we discover commits in depth order,
so the discovery process is robust against interruption/failure. If we just
inserted commits as we went, we might read the tip, insert it, and then crash.
When we ran again, we'd think we had already discovered commits older than HEAD.
This also allows later stages to rely on being able to find Phabricator commit
IDs which correspond to parent commits.
NOTE: This importer is fairly slow because "hg" has a large startup time
(compare "hg --version" to "git --version" and "svn --version"; on my machine,
hg has 60ms of overhead for any command) and we need to run many commands (see
the whole "hg id" mess). You can expect something like 10,000 per hour, which
means you may need to run overnight to discover a large repository (IIRC, the
svn/git discovery processes are both about an order of magnitude faster). We
could improve this with batching, but I want to keep it as simple as possible
for now.
Test Plan: Discovered all the commits in the main Mercurial repository,
http://selenic.com/repo/hg.
Reviewers: Makinde, jungejason, nh, tuomaspelkonen, aran
Reviewed By: Makinde
CC: aran, Makinde
Differential Revision: 943
2011-09-16 12:56:23 +02:00
|
|
|
'PhabricatorRepositoryMercurialCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
|
2011-09-16 18:37:15 +02:00
|
|
|
'PhabricatorRepositoryMercurialCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
|
2011-08-09 21:47:46 +02:00
|
|
|
'PhabricatorRepositoryMercurialPullDaemon' => 'PhabricatorRepositoryPullLocalDaemon',
|
|
|
|
'PhabricatorRepositoryPullLocalDaemon' => 'PhabricatorRepositoryDaemon',
|
2011-03-31 09:33:44 +02:00
|
|
|
'PhabricatorRepositoryShortcut' => 'PhabricatorRepositoryDAO',
|
2011-03-11 23:13:23 +01:00
|
|
|
'PhabricatorRepositorySvnCommitChangeParserWorker' => 'PhabricatorRepositoryCommitChangeParserWorker',
|
2011-03-11 18:34:22 +01:00
|
|
|
'PhabricatorRepositorySvnCommitDiscoveryDaemon' => 'PhabricatorRepositoryCommitDiscoveryDaemon',
|
|
|
|
'PhabricatorRepositorySvnCommitMessageParserWorker' => 'PhabricatorRepositoryCommitMessageParserWorker',
|
2011-09-05 02:31:16 +02:00
|
|
|
'PhabricatorRepositorySymbol' => 'PhabricatorRepositoryDAO',
|
2011-12-23 17:11:11 +01:00
|
|
|
'PhabricatorRepositoryTestCase' => 'PhabricatorTestCase',
|
2011-07-31 22:54:58 +02:00
|
|
|
'PhabricatorS3FileStorageEngine' => 'PhabricatorFileStorageEngine',
|
2012-03-10 00:46:25 +01:00
|
|
|
'PhabricatorSearchAttachController' => 'PhabricatorSearchBaseController',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchBaseController' => 'PhabricatorController',
|
2011-06-20 06:02:48 +02:00
|
|
|
'PhabricatorSearchCommitIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchController' => 'PhabricatorSearchBaseController',
|
|
|
|
'PhabricatorSearchDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorSearchDifferentialIndexer' => 'PhabricatorSearchDocumentIndexer',
|
|
|
|
'PhabricatorSearchDocument' => 'PhabricatorSearchDAO',
|
|
|
|
'PhabricatorSearchDocumentField' => 'PhabricatorSearchDAO',
|
|
|
|
'PhabricatorSearchDocumentRelationship' => 'PhabricatorSearchDAO',
|
[NO CLUE WHAT I'M DOING] Add an Elasticsearch engine
Summary:
I have no idea what I'm doing, but here's part of an elasticsearch engine. These things work:
- Indexing stuff (??)
- Searching for text/type?
- Reconstructing things??
All the complicated stuff doesn't work. I'm having a hard time figuring out the best way to model things because elasticsearch's documentation is not exactly the most complete or illuminating.
@amckinley, does this look sane-ish so far? Particularly, the /phabricator/<type>/<phid>/ URI scheme and how I've set up the relationships and fields in the documents?
How should I model the relationship and field queries? I want, like, an "equal" query but it seems like I've got "text" or "term" to work with and neither are exact match? And "term" doesn't consider PHIDs to be terms since they have hyphens in them?
I'll keep kind of slogging my way forward here but if you have valuable wisdom to share it would probably get me to a better end state much faster. The whole query construction phase is pretty much black magic to me.
Test Plan: nyancat
Reviewers: amckinley, vrana
Reviewed By: vrana
CC: jungejason, tuomaspelkonen, aran, 20after4, vrana
Differential Revision: https://secure.phabricator.com/D790
2012-04-21 00:33:09 +02:00
|
|
|
'PhabricatorSearchEngineElastic' => 'PhabricatorSearchEngine',
|
2011-08-08 00:14:23 +02:00
|
|
|
'PhabricatorSearchEngineMySQL' => 'PhabricatorSearchEngine',
|
2011-06-15 16:43:43 +02:00
|
|
|
'PhabricatorSearchIndexController' => 'PhabricatorSearchBaseController',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchManiphestIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2011-07-12 02:29:08 +02:00
|
|
|
'PhabricatorSearchPhrictionIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2011-02-15 00:34:20 +01:00
|
|
|
'PhabricatorSearchQuery' => 'PhabricatorSearchDAO',
|
Improve search result listing
Summary:
Make it prettier, paginate, add user pictures, show document types, clean some
stuff up a little. Plenty of room for improvement but this should make it a lot
more useful.
Test Plan:
Here's what the new one looks like:
https://secure.phabricator.com/file/view/PHID-FILE-edce2b83c2e3a121c2b7/
Reviewed By: jungejason
Reviewers: tomo, jungejason, aran, tuomaspelkonen, mroch
Commenters: tomo
CC: aran, tomo, jungejason, epriestley
Differential Revision: 545
2011-06-28 23:35:02 +02:00
|
|
|
'PhabricatorSearchResultView' => 'AphrontView',
|
2012-03-10 00:46:25 +01:00
|
|
|
'PhabricatorSearchSelectController' => 'PhabricatorSearchBaseController',
|
2011-06-23 22:31:20 +02:00
|
|
|
'PhabricatorSearchUserIndexer' => 'PhabricatorSearchDocumentIndexer',
|
2011-07-08 20:13:11 +02:00
|
|
|
'PhabricatorSlowvoteChoice' => 'PhabricatorSlowvoteDAO',
|
|
|
|
'PhabricatorSlowvoteComment' => 'PhabricatorSlowvoteDAO',
|
|
|
|
'PhabricatorSlowvoteController' => 'PhabricatorController',
|
|
|
|
'PhabricatorSlowvoteCreateController' => 'PhabricatorSlowvoteController',
|
|
|
|
'PhabricatorSlowvoteDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorSlowvoteListController' => 'PhabricatorSlowvoteController',
|
|
|
|
'PhabricatorSlowvoteOption' => 'PhabricatorSlowvoteDAO',
|
|
|
|
'PhabricatorSlowvotePoll' => 'PhabricatorSlowvoteDAO',
|
|
|
|
'PhabricatorSlowvotePollController' => 'PhabricatorSlowvoteController',
|
2012-04-10 23:18:20 +02:00
|
|
|
'PhabricatorSlugTestCase' => 'PhabricatorTestCase',
|
2012-03-20 03:48:22 +01:00
|
|
|
'PhabricatorSortTableExample' => 'PhabricatorUIExample',
|
2011-01-23 02:48:55 +01:00
|
|
|
'PhabricatorStandardPageView' => 'AphrontPageView',
|
2011-04-08 20:13:29 +02:00
|
|
|
'PhabricatorStatusController' => 'PhabricatorController',
|
2011-08-30 22:12:20 +02:00
|
|
|
'PhabricatorSymbolNameLinter' => 'ArcanistXHPASTLintNamingHook',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorTaskmasterDaemon' => 'PhabricatorDaemon',
|
2011-04-30 19:11:41 +02:00
|
|
|
'PhabricatorTestCase' => 'ArcanistPhutilTestCase',
|
2011-03-07 07:29:22 +01:00
|
|
|
'PhabricatorTimelineCursor' => 'PhabricatorTimelineDAO',
|
|
|
|
'PhabricatorTimelineDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorTimelineEvent' => 'PhabricatorTimelineDAO',
|
|
|
|
'PhabricatorTimelineEventData' => 'PhabricatorTimelineDAO',
|
2011-06-13 01:06:17 +02:00
|
|
|
'PhabricatorTimer' => 'PhabricatorCountdownDAO',
|
2012-02-24 22:02:35 +01:00
|
|
|
'PhabricatorTransactionView' => 'AphrontView',
|
2011-05-22 23:40:51 +02:00
|
|
|
'PhabricatorTransformedFile' => 'PhabricatorFileDAO',
|
2011-08-03 17:17:53 +02:00
|
|
|
'PhabricatorTrivialTestCase' => 'PhabricatorTestCase',
|
2011-01-25 22:48:05 +01:00
|
|
|
'PhabricatorTypeaheadCommonDatasourceController' => 'PhabricatorTypeaheadDatasourceController',
|
|
|
|
'PhabricatorTypeaheadDatasourceController' => 'PhabricatorController',
|
2011-04-01 02:06:33 +02:00
|
|
|
'PhabricatorUIExampleController' => 'PhabricatorController',
|
|
|
|
'PhabricatorUIExampleRenderController' => 'PhabricatorUIExampleController',
|
2011-04-04 00:50:06 +02:00
|
|
|
'PhabricatorUIListFilterExample' => 'PhabricatorUIExample',
|
2011-04-01 02:06:33 +02:00
|
|
|
'PhabricatorUIPagerExample' => 'PhabricatorUIExample',
|
2012-03-13 02:21:02 +01:00
|
|
|
'PhabricatorUITooltipExample' => 'PhabricatorUIExample',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorUser' => 'PhabricatorUserDAO',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserAccountSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
|
|
|
'PhabricatorUserConduitSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-01-24 03:09:16 +01:00
|
|
|
'PhabricatorUserDAO' => 'PhabricatorLiskDAO',
|
Add optional "Re:" prefix to all threaded mail and allow disabling mail about
your own actions
Summary:
- Mail.app on Lion has cumbersome threading rules, see T782. Add an option to
stick "Re: " in front of all threaded mail so it behaves. This is horrible, but
apparently the least-horrible option.
- While I was in there, I added an option for T228.
Test Plan:
- Sent a bunch of threaded and unthreaded mail with varous "Re:" settings,
seemed to get "Re:" in the right places.
- Disabled email about my stuff, created a task with just me, got voided mail,
added a CC, got mail to just the CC.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, mkjones
Maniphest Tasks: T228, T782
Differential Revision: https://secure.phabricator.com/D1448
2012-01-18 05:32:28 +01:00
|
|
|
'PhabricatorUserEmailPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserEmailSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
Provide an activity log for login and administrative actions
Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish.
Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen:
- The log itself is useful if there are shenanigans.
- Password login can check it and start CAPTCHA'ing users after a few failed attempts.
I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow.
Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways.
Reviewers: jungejason, tuomaspelkonen, aran
CC:
Differential Revision: 302
2011-05-18 03:42:21 +02:00
|
|
|
'PhabricatorUserLog' => 'PhabricatorUserDAO',
|
2011-02-21 07:47:56 +01:00
|
|
|
'PhabricatorUserOAuthInfo' => 'PhabricatorUserDAO',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserOAuthSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
Add change password settings panel
Summary:
In password-based auth environments, there is now a user settings
panel to allow them to change their password.
Test Plan:
Click settings, choose password from the left:
* enter current password, new password (twice), log out, and log in with
new password
* enter current password, non-matching passwords, and get error
* enter invalid old password, and get error
* use firebug to change csrf token and verify that it does not save with
and invalid token
Changed config to disable password auth, loaded settings panel and saw
that password was no longer visible. Tried loading the panel anyway and
got redirected.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley
Differential Revision: 890
2011-09-04 10:53:58 +02:00
|
|
|
'PhabricatorUserPasswordSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-07-24 20:02:08 +02:00
|
|
|
'PhabricatorUserPreferenceSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-03-31 04:21:09 +02:00
|
|
|
'PhabricatorUserPreferences' => 'PhabricatorUserDAO',
|
2011-02-20 03:28:41 +01:00
|
|
|
'PhabricatorUserProfile' => 'PhabricatorUserDAO',
|
2011-07-25 00:03:59 +02:00
|
|
|
'PhabricatorUserProfileSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-07-22 19:17:57 +02:00
|
|
|
'PhabricatorUserSSHKey' => 'PhabricatorUserDAO',
|
|
|
|
'PhabricatorUserSSHKeysSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2012-03-15 04:47:17 +01:00
|
|
|
'PhabricatorUserSearchSettingsPanelController' => 'PhabricatorUserSettingsPanelController',
|
2011-02-06 07:36:21 +01:00
|
|
|
'PhabricatorUserSettingsController' => 'PhabricatorPeopleController',
|
2011-07-18 17:02:00 +02:00
|
|
|
'PhabricatorUserSettingsPanelController' => 'PhabricatorPeopleController',
|
2012-01-16 16:30:28 +01:00
|
|
|
'PhabricatorUserTestCase' => 'PhabricatorTestCase',
|
2011-03-10 22:48:29 +01:00
|
|
|
'PhabricatorWorkerDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorWorkerTask' => 'PhabricatorWorkerDAO',
|
|
|
|
'PhabricatorWorkerTaskData' => 'PhabricatorWorkerDAO',
|
2011-03-27 07:55:18 +02:00
|
|
|
'PhabricatorWorkerTaskDetailController' => 'PhabricatorDaemonController',
|
2012-01-24 01:36:32 +01:00
|
|
|
'PhabricatorWorkerTaskUpdateController' => 'PhabricatorDaemonController',
|
2011-04-07 04:17:05 +02:00
|
|
|
'PhabricatorXHPASTViewController' => 'PhabricatorController',
|
|
|
|
'PhabricatorXHPASTViewDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhabricatorXHPASTViewFrameController' => 'PhabricatorXHPASTViewController',
|
|
|
|
'PhabricatorXHPASTViewFramesetController' => 'PhabricatorXHPASTViewController',
|
|
|
|
'PhabricatorXHPASTViewInputController' => 'PhabricatorXHPASTViewPanelController',
|
|
|
|
'PhabricatorXHPASTViewPanelController' => 'PhabricatorXHPASTViewController',
|
|
|
|
'PhabricatorXHPASTViewParseTree' => 'PhabricatorXHPASTViewDAO',
|
|
|
|
'PhabricatorXHPASTViewRunController' => 'PhabricatorXHPASTViewController',
|
|
|
|
'PhabricatorXHPASTViewStreamController' => 'PhabricatorXHPASTViewPanelController',
|
|
|
|
'PhabricatorXHPASTViewTreeController' => 'PhabricatorXHPASTViewPanelController',
|
2011-02-02 22:48:52 +01:00
|
|
|
'PhabricatorXHProfController' => 'PhabricatorController',
|
|
|
|
'PhabricatorXHProfProfileController' => 'PhabricatorXHProfController',
|
2012-01-28 20:17:19 +01:00
|
|
|
'PhabricatorXHProfProfileSymbolView' => 'PhabricatorXHProfProfileView',
|
|
|
|
'PhabricatorXHProfProfileTopLevelView' => 'PhabricatorXHProfProfileView',
|
|
|
|
'PhabricatorXHProfProfileView' => 'AphrontView',
|
2012-04-12 22:09:04 +02:00
|
|
|
'PhameController' => 'PhabricatorController',
|
|
|
|
'PhameDAO' => 'PhabricatorLiskDAO',
|
|
|
|
'PhameDraftListController' => 'PhamePostListBaseController',
|
|
|
|
'PhamePost' => 'PhameDAO',
|
|
|
|
'PhamePostDeleteController' => 'PhameController',
|
|
|
|
'PhamePostDetailView' => 'AphrontView',
|
|
|
|
'PhamePostEditController' => 'PhameController',
|
|
|
|
'PhamePostListBaseController' => 'PhameController',
|
|
|
|
'PhamePostListController' => 'PhamePostListBaseController',
|
|
|
|
'PhamePostListView' => 'AphrontView',
|
|
|
|
'PhamePostPreviewController' => 'PhameController',
|
|
|
|
'PhamePostQuery' => 'PhabricatorOffsetPagedQuery',
|
|
|
|
'PhamePostViewController' => 'PhameController',
|
2012-04-05 01:09:29 +02:00
|
|
|
'PhortuneMonthYearExpiryControl' => 'AphrontFormControl',
|
|
|
|
'PhortuneStripeBaseController' => 'PhabricatorController',
|
|
|
|
'PhortuneStripePaymentFormView' => 'AphrontView',
|
|
|
|
'PhortuneStripeTestPaymentFormController' => 'PhortuneStripeBaseController',
|
2011-07-12 16:23:04 +02:00
|
|
|
'PhrictionActionConstants' => 'PhrictionConstants',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionChangeType' => 'PhrictionConstants',
|
2011-07-11 21:34:53 +02:00
|
|
|
'PhrictionContent' => 'PhrictionDAO',
|
2011-07-11 17:54:22 +02:00
|
|
|
'PhrictionController' => 'PhabricatorController',
|
|
|
|
'PhrictionDAO' => 'PhabricatorLiskDAO',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionDeleteController' => 'PhrictionController',
|
2011-07-17 20:06:02 +02:00
|
|
|
'PhrictionDiffController' => 'PhrictionController',
|
2011-07-11 17:54:22 +02:00
|
|
|
'PhrictionDocument' => 'PhrictionDAO',
|
|
|
|
'PhrictionDocumentController' => 'PhrictionController',
|
2011-07-17 03:25:45 +02:00
|
|
|
'PhrictionDocumentPreviewController' => 'PhrictionController',
|
2011-12-17 18:19:08 +01:00
|
|
|
'PhrictionDocumentStatus' => 'PhrictionConstants',
|
2011-07-12 17:08:03 +02:00
|
|
|
'PhrictionDocumentTestCase' => 'PhabricatorTestCase',
|
2011-07-11 21:34:53 +02:00
|
|
|
'PhrictionEditController' => 'PhrictionController',
|
2011-07-12 00:06:19 +02:00
|
|
|
'PhrictionHistoryController' => 'PhrictionController',
|
2011-07-12 00:42:12 +02:00
|
|
|
'PhrictionListController' => 'PhrictionController',
|
2011-12-14 02:34:41 +01:00
|
|
|
'QueryFormattingTestCase' => 'PhabricatorTestCase',
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
|
|
|
'requires_interface' =>
|
|
|
|
array(
|
2012-04-10 18:46:04 +02:00
|
|
|
'DefaultDatabaseConfigurationProvider' =>
|
|
|
|
array(
|
|
|
|
0 => 'DatabaseConfigurationProvider',
|
|
|
|
),
|
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
|
|
|
'DifferentialInlineComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorInlineCommentInterface',
|
|
|
|
),
|
|
|
|
'PhabricatorAuditInlineComment' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorInlineCommentInterface',
|
|
|
|
),
|
Add basic per-object privacy policies
Summary:
Provides a basic start for access policies. Objects expose various capabilities, like CAN_VIEW, CAN_EDIT, etc., and set a policy for each capability. We currently implement three policies, PUBLIC (anyone, including logged-out), USERS (any logged-in) and NOONE (nobody). There's also a way to provide automatic capability grants (e.g., the owner of an object can always see it, even if some capability is set to "NOONE"), but I'm not sure how great the implementation feels and it might change.
Most of the code here is providing a primitive for efficient policy-aware list queries. The problem with doing queries naively is that you have to do crazy amounts of filtering, e.g. to show the user page 6, you need to filter at least 600 objects (and likely more) before you can figure out which ones are 500-600 for them. You can't just do "LIMIT 500, 100" because that might have only 50 results, or no results. Instead, the query looks like "WHERE id > last_visible_id", and then we fetch additional pages as necessary to satisfy the request.
The general idea is that we move all data access to Query classes and have them do object filtering. The ID paging primitive allows efficient paging in most cases, and the executeOne() method provides a concise way to do policy checks for edit/view screens.
We'll probably end up with mostly broader policy UIs or configuration-based policies, but there are at least a few cases for per-object privacy (e.g., marking tasks as "Security", and restricting things to the members of projects) so I figured we'd start with a flexible primitive and the simplify it in the UI where we can.
Test Plan: Unit tests, played around in the UI with various policy settings.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603
Differential Revision: https://secure.phabricator.com/D2210
2012-04-14 19:13:29 +02:00
|
|
|
'PhabricatorPaste' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
|
|
|
'PhabricatorPolicyTestObject' =>
|
|
|
|
array(
|
|
|
|
0 => 'PhabricatorPolicyInterface',
|
|
|
|
),
|
2011-01-16 22:51:39 +01:00
|
|
|
),
|
|
|
|
));
|