Summary: I used the `PhabricatorEnv::getProductionURI()` in too many places to build Releeph URIs. The only places that should need full URIs are the links generated for Releeph emails, and in Conduit responses that link to Releeph objects.
Test Plan:
- Grep for `getProductionURI()` in Releeph, and make sure only sensible, non-DOM building places use it.
- Inspect the Releeph DOM to make sure hrefs etc. are relative.
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5999
Summary:
Moves all remaining mail handling into ReplyHandlers.
Farewell, `getPhabricatorToInformation()`! You were a bad method and no one liked you.
Ref T1205.
Test Plan:
- Used test console to send mail to Revisions, Tasks, Conpherences and Commits (these all actually work).
- Used test console to send mail to Requests, Macros, Questions and Mocks (these accept the mail but don't do anything with it, but didn't do anything before either).
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1205
Differential Revision: https://secure.phabricator.com/D5953
Summary: This doesn't do anything, but touches a bunch of files so I split it out to reduce the size of the next diff. Basically, make `MailReceiver` classes responsible for loading their application objects. Ref T1205.
Test Plan: Inspection / next diff / code is not reached.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1205
Differential Revision: https://secure.phabricator.com/D5941
Summary: Ref T2784. This one was a wee bit complicated. Had to add PhabricatorUser and concept of initFromConduit (or not) to DiffusionRequest.
Test Plan: foreach repo, visited CALLSIGN and clicked a commit and verified they laoded correctly. Hacked code to hit NOT via Conduit and repeated tests to great success.
Reviewers: epriestley
Reviewed By: epriestley
CC: chad, aran, Korvin
Maniphest Tasks: T2784
Differential Revision: https://secure.phabricator.com/D5928
Summary:
Ref T1205. Continuation of D5915.
Currently, `PhabricatorMetaMTAReceivedMail` has //all// the logic for routing mail. In particular:
- New mail receivers in applications must edit it.
- Mail receivers don't drop out when applications are uninstalled.
Applications have some logic in subclasses of `PhabricatorMailReplyHandler`, but this class is a bit of a mess. It is also heavily based on the assumption that mail receivers are objects (like revisions), but this is not true in at least two cases today (creating new tasks with `bugs@`, creating a new Conpherence thread) and likely other cases in the future (e.g., revision-by-mail).
Move this logic into a new `PhabricatorMailReceiver` classtree. This is similar to `PhabricatorMailReplyHandler` but a bit cleaner and more general. I plan to heavily reduce the responsibilities of `PhabricatorMailReplyHandler` or possibly eliminate it entirely.
For now, the new classtree doesn't do much of interest. The only behavioral change this diff causes is that Phabricator will now reject mail to an application when that application is uninstalled.
I also moved all the `ReplyHandler` classes into `mail/` directories in their respective applications.
Test Plan: Unit tests, used receive test to route mail to various objects.
Reviewers: btrahan
Reviewed By: btrahan
CC: Afaque_Hussain, edward, aran
Maniphest Tasks: T1205
Differential Revision: https://secure.phabricator.com/D5922
Summary: This is just a bit of gardening in order to make the responsive-UI diff easier; I'll be putting `getColorFor($status)` type things in this class, following the pattern in `ManiphestTaskStatus`.
Test Plan: Poke around Releeph.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5893
Summary:
Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions. Email is supported in the standard way (no more `ReleephRequestMail`) as well.
This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.)
Test Plan:
* Make requests, then pick them.
* Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening.
* Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.)
* Load all of FB's Releeph data into my DB and run the `storage upgrade` script.
* Request a commit via the "action" in a Differential revision.
Reviewers: epriestley
Reviewed By: epriestley
CC: epriestley, aran, Korvin, wez
Maniphest Tasks: T3092, T2720
Differential Revision: https://secure.phabricator.com/D5868
Summary: Oops, `pht()` interpolates percent escape sequences, but this is a literal "%N".
Test Plan: Edit a Releeph project; notice no errors.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5897
Summary: I wrote some of the Releeph-project edit-page's help in remarkup. This renders the remarkup using the `PhabricatorMarkupEngine` pipeline.
Test Plan:
* Edit a Releeph project.
* Feel the cool base of a laptop whose CPU is no longer being thrashed by onerous remarkup rendering duties.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3098
Differential Revision: https://secure.phabricator.com/D5898
Summary: Instead of being able to ask if someone was a pusher or not, ask if they are "authoritative" enough to make decisions about Releeph requests. A person is authoritative if a project has pushers, and they are a pusher, or in the case of pusher-less projects, everyone is authoritative.
Test Plan: Make a request in a project with no pushers (it is immediately ready to be picked) and a project with pushers (where it requires approval.)
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, aran
Differential Revision: https://secure.phabricator.com/D5877
Summary: Adding mail-keys; required for `PhabricatorApplicationTransaction` support.
Test Plan: Upgrade an old database with this patch, observe the matrix: {F42620}
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, aran
Maniphest Tasks: T2720
Differential Revision: https://secure.phabricator.com/D5852
Summary:
Removing a bunch of cache-style columns from `ReleephRequest`, where it's actually much easier to just load the information at runtime.
This makes sense for migrating to `PhabricatorApplicationTransactions`, where each xaction changes one aspect of a `ReleephRequest` at a time (rather than multiple columns at once.)
Test Plan: Request something, run `arc releeph` and watch the picks, pass on some RQs, run `arc releeph` and watch the reverts.
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, aran
Maniphest Tasks: T2720
Differential Revision: https://secure.phabricator.com/D5851
Summary: Not every commit requested in Releeph has to have come from a Differential revision. If you have a Releeph request for a commit without a Differential revision, you currently get this lovely error in the logs: {P824}. This diff silences the howling.
Test Plan: Load a Releeph branch page; observe log silence.
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, aran, SEJeff, Korvin
Differential Revision: https://secure.phabricator.com/D5823
Summary: Use a single `PhabricatorMarkupEngine` to render any markup in Releeph's fields, rather than rendering everything from scratch every time.
Test Plan: Check out the "Services" tab in the dark console when rendering a page on a branch page with 500x RQs!
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, aran
Maniphest Tasks: T3098
Differential Revision: https://secure.phabricator.com/D5822
Summary:
`ReleephRequest`s contain the PHID for a `PhabricatorRepositoryCommit`, and commits have an edge to a `DifferentialRevision`.
Commits are loaded with the `loadOneRelative()` method that loads the commits for every `ReleephRequest` in a `LiskDAOSet`, but the edges are loaded indivdually. A page with N RQs on it makes one DB query for the commits, but N queries for the `TYPE_COMMIT_HAS_DREV` edges.
This diff uses `loadRelativeEdges` instead to load the edges all in one query.
Test Plan: {F42290}
Reviewers: wez, epriestley
Reviewed By: epriestley
CC: epriestley, vrana, aran
Maniphest Tasks: T2714
Differential Revision: https://secure.phabricator.com/D5820
Summary: Went and pht'd most everything I could find, except exceptions. Fixes T3091
Test Plan: Bopped around the application, didn't seem to break anything but didn't test all flows. Should be safe.
Reviewers: epriestley, edward
Reviewed By: epriestley
CC: aran, Korvin
Maniphest Tasks: T3091
Differential Revision: https://secure.phabricator.com/D5825
Summary: Migration doesn't delete differential.revisionPHID but maybe it should?
Test Plan: Reparsed commit, ran the migration, deleted differential.revisionPHID, looked at task with attached commit with attached revision.
Reviewers: epriestley, edward
Reviewed By: epriestley
CC: aran, Korvin, AnhNhan
Differential Revision: https://secure.phabricator.com/D5634
Summary:
Adds a policy-aware query class for selecting Releeph projects. This doesn't really change anything.
- Make `ReleephProject` implment `PhabricatorPolicyInterface`, beginning the long journey to make it policy-aware.
- Implement `ReleephProjectQuery`, for querying projects using cursor-based, policy-aware paging.
- Use it on the list view, so we load only ~100 projects instead of all of them.
- Tweaked some of the URI routing stuff to make it a little more consistent with common practices.
Ref T2714.
Test Plan:
{F36434}
{F36435}
Reviewers: edward
Reviewed By: edward
CC: aran
Maniphest Tasks: T2714
Differential Revision: https://secure.phabricator.com/D5390
Summary:
When submitting a diff I noticed that the unit test `testEverythingImplemented` threw an error that did not fail a test.
```
[2013-03-18 16:35:16] ERROR 2048: Declaration of ReleephRequestDifferentialCreateController::willProcessRequest() should be compatible with AphrontController::willProcessRequest(array $uri_data) at [/home/anhnhan/dev/vanilla/phabricator/src/applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php:99]
#0 PhutilBootloader::executeInclude called at [/home/anhnhan/dev/vanilla/libphutil/src/__phutil_library_init__.php:203]
#1 PhutilBootloader::executeInclude(/home/anhnhan/dev/vanilla/phabricator/src/applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php) called at [/home/anhnhan/dev/vanilla/libphutil/src/__phutil_library_init__.php:193]
#2 PhutilBootloader::loadLibrarySource(phabricator, applications/releeph/controller/request/ReleephRequestDifferentialCreateController.php) called at [/home/anhnhan/dev/vanilla/libphutil/src/symbols/PhutilSymbolLoader.php:341]
#3 PhutilSymbolLoader::loadSymbol(Array of size 4 starting with: { type => class }) called at [/home/anhnhan/dev/vanilla/libphutil/src/symbols/PhutilSymbolLoader.php:246]
#4 PhutilSymbolLoader::selectAndLoadSymbols() called at [/home/anhnhan/dev/vanilla/phabricator/src/infrastructure/__tests__/PhabricatorInfrastructureTestCase.php:15]
#5 PhabricatorInfrastructureTestCase::testEverythingImplemented()
#6 call_user_func_array(Array of size 2 starting with: { 0 => Object PhabricatorInfrastructureTestCase }, Array ) called at [/home/anhnhan/dev/vanilla/arcanist/src/unit/engine/phutil/ArcanistPhutilTestCase.php:441]
#7 ArcanistPhutilTestCase::run() called at [/home/anhnhan/dev/vanilla/arcanist/src/unit/engine/PhutilUnitTestEngine.php:60]
#8 PhutilUnitTestEngine::run() called at [/home/anhnhan/dev/vanilla/arcanist/src/workflow/ArcanistUnitWorkflow.php:160]
#9 ArcanistUnitWorkflow::run() called at [/home/anhnhan/dev/vanilla/arcanist/scripts/arcanist.php:271]
```
Test Plan:
`arc unit --everything` before this change gave error.
applied this change. Re-ran `arc unit --everything`, no error.
Reviewers: edward
Reviewed By: edward
CC: aran, epriestley
Differential Revision: https://secure.phabricator.com/D5373
Summary: Return an array of renderables instead of rendering things ourselves (which we used to do with `AphrontView->renderSingleView()`.)
Test Plan: View a Releeph branch; gloriously notice no deprecated warnings.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5363
Summary: Oops. Functions only return stuff when you call the `return()` function on the `lvalue`.
Test Plan: Use `ReleephDefaultFieldSelector` is the field selector in a test Releeph project.
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, Korvin
Differential Revision: https://secure.phabricator.com/D5362
