Summary: Ref T3663. Same as D6785, but for branches. No writes to this table yet.
Test Plan: Clicked "View History", got a blank but non-broken page.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3663
Differential Revision: https://secure.phabricator.com/D6787
Summary: Ref T3663. There's no data recorded in this table yet, but add the UI and controller for it. Edits and such will eventually go here.
Test Plan: Clicked "View History" on a project, got an empty but non-broken page.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T3663
Differential Revision: https://secure.phabricator.com/D6785
Summary:
Releeph branch lists in project views have a bunch of custom UI right now; give them more standard UI and ApplicationSearch.
This drops a small piece of functionality: we now show only a total open request count instead of a detailed enumeration of each request status. I assume this is reasonable (that is, the important piece is "is there something to do on this branch?"), but we can muck with it if the more detailed status is important.
Test Plan: {F54344}
Reviewers: btrahan
Reviewed By: btrahan
CC: LegNeato, aran
Maniphest Tasks: T3656
Differential Revision: https://secure.phabricator.com/D6764
Summary:
Ref T3721. Releeph currently attempts to implement a flexible, field-driven search for branches, but it's building all of its own infrastructure and it ends up heading down some weird paths. In particular, it loads **every** request and then makes calls into fields to filter them. It also tries to be very very general, which isn't really necessary (for example, I think it's reasonable for us to assume that we won't let you disable the "requestor" field).
ApplicationSearch and CustomField provide more scalable approaches to this problem; move search on top of them. The query still ends up doing some filtering in-process, but it's now far more limited in scope and can be denormalized later.
Test Plan: {F54304}
Reviewers: btrahan
Reviewed By: btrahan
CC: chad, aran
Maniphest Tasks: T3721
Differential Revision: https://secure.phabricator.com/D6758
Summary: Ref T3656. Releeph denormalizes branch cut point identifiers into Branch objects, but this information isn't useful or used for sorting, filtering, or enforcing unique constraints. Instead, derive it via noramlized pathways from the `cutPointCommitPHID`.
Test Plan: Ran storage upgrade. Ran `releephwork.getbranch` and `releeph.getbranches`. Grepped for `cutPointCommitIdentifier`.
Reviewers: btrahan
Reviewed By: btrahan
CC: LegNeato, aran
Maniphest Tasks: T3656
Differential Revision: https://secure.phabricator.com/D6636
Summary:
Ref T3655. ReleephProject currently has both `repositoryID` and `repositoryPHID`, which point to the same object and are reudundant. Get rid of all reads of `repositoryID`.
NOTE: This makes project loads depend on repository loads. The eventual rule here will be that you must be able to see a repository in order to see projects for that repository, which seems like a reasonable rule. We might need to tailor it more than this (e.g., if there are branch read permissions down the line) but this seems like a reasonable minimum.
Test Plan: Grepped for `repositoryID` in `releeph/`. Called `releeph.getbranches`.
Reviewers: btrahan
Reviewed By: btrahan
CC: LegNeato, aran
Maniphest Tasks: T3655
Differential Revision: https://secure.phabricator.com/D6633
Summary:
Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small:
- We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write.
- We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results.
- Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project.
- Implement `ReleephBranchQuery`.
- Move the branch PHID type to application PHID infrastructure.
Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs.
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T603, T2715, T3551
Differential Revision: https://secure.phabricator.com/D6512
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:
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:
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
