Summary:
Fixes T3660. Releeph Projects currently have an unused one-to-one mapping to Phabricator projects. This isn't consistent with other applications and has no integrations or uses. Get rid of it.
NOTE: Waiting for signoff from @legneato on T3660 before pulling the trigger here.
Test Plan: Created and edited Releeph projects. Grepped for references to project ID; there are a dozen or so but they're all either Releeph projects or Arcanist projects.
Reviewers: btrahan
Reviewed By: btrahan
CC: LegNeato, aran
Maniphest Tasks: T3660
Differential Revision: https://secure.phabricator.com/D6635
Summary: Ref T3655. Depends on D6633. This removes the writes and the column.
Test Plan: Created a project, edited a project. Verified the table doesn't have any keys including this column.
Reviewers: btrahan
Reviewed By: btrahan
CC: LegNeato, aran
Maniphest Tasks: T3655
Differential Revision: https://secure.phabricator.com/D6634
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: 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: 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:
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
