1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-13 18:32:41 +01:00
Commit graph

53 commits

Author SHA1 Message Date
Joshua Spence
0a62f13464 Change double quotes to single quotes.
Summary: Ran `arc lint --apply-patches --everything` over rP, mainly to change double quotes to single quotes where appropriate. These changes also validate that the `ArcanistXHPASTLinter::LINT_DOUBLE_QUOTE` rule is working as expected.

Test Plan: Eyeballed it.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D9431
2014-06-09 11:36:50 -07:00
Chad Little
11fd6afeb1 Move Timeline icons to Fonts
Summary: Throwing this up for testing, swapped out all icons in timeline for their font equivelants. Used better icons where I could as well. We should feel free to use more / be fun with the icons when possible since there is no penalty anymore.

Test Plan: I browsed many, not all, timelines in my sandbox and in IE8. Some of these were just swagged, but I'm expecting we'll do more SB testing before landing.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D8827
2014-04-22 08:25:54 -07:00
epriestley
28696d08ac Remove indirect loads of Differential revisions from Releeph requests
Summary:
Ref T3551. Currently, there are many layers of indirection between pull requests and revisions. After D8822, revisions and other types of requested objects are recorded directly on the request. This allows us to simplify data access and querying.

A lot of stuff here is doing `instanceof` checks to keep APIs stable, but most of those can go away in the long run.

Test Plan:
  - Browsed requests.
  - Verified revision-dependent fields (like "Revision", "Size", "Churn") still render correctly.
  - Called `releeph.queryrequests`.
  - Called `releephwork.nextrequest`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3551

Differential Revision: https://secure.phabricator.com/D8824
2014-04-20 11:55:47 -07:00
epriestley
1a3ac09975 Add "requestedObjectPHID" to ReleephRequest
Summary:
Ref T3551. Currently, ReleephRequests don't have a direct concept of the //object// being requested. You can request `D123`, but that is just a convenient way to write `rXyyyy`.

When the UI wants to display information about a revision, it deduces it by examining the commit.

This is primarily an attack on T3551, so we don't need to load <commit -> edge -> revision> (in an ad-hoc way) to get revisions. Instead, when you request a revision we keep track of it and can load it directly later.

Later, this will let us do more things: for example, if you request a branch, we can automatically update the commits (as GitHub does), etc. (Repository branches will need PHIDs first, of course.)

This adds and populates the column but doesn't use it yet. The second part of the migration could safely be run while Phabricator is up, although even for Facebook this table is probably quite small.

Test Plan:
  - Ran migration.
  - Verified existing requests associated sensibly.
  - Created a new commit request.
  - Created a new revision request.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3551

Differential Revision: https://secure.phabricator.com/D8822
2014-04-20 11:55:18 -07:00
epriestley
a588955bf7 Remove loadPhabricatorRepository from ReleephProject
Summary: Ref T3551. Repository is guaranteed if a product is loaded with modern mechanisms.

Test Plan:
  - Edited a request.
  - Called `releephwork.getbranchcommitmessage`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3551

Differential Revision: https://secure.phabricator.com/D8821
2014-04-20 11:55:09 -07:00
epriestley
d75d0acba5 Remove loadReleephBranch and loadReleephProject from ReleephRequest
Summary: Ref T3551. Ref T3549. Mostly unnecessary with modern calls.

Test Plan:
- Called `releeph.queryrequests`.
- Called `releeph.request`.
- Called `releephwork.getbranchcommitmessage`.
- Called `releephwork.getcommitmessage`.
- Called `releephwork.nextrequest`.
- Viewed and edited branches and requests.
- Made a comment on a request.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3549, T3551

Differential Revision: https://secure.phabricator.com/D8820
2014-04-20 11:54:58 -07:00
epriestley
a4f975ef3e Remove some ad-hoc handle loads from Releeph
Summary:
Ref T3551. Releeph does a bunch of old-school on-object data loading; start cleaning that up.

This doesn't change anything, just makes the code more modern/consistent.

Test Plan: Edited a request; called `releephwork.nextrequest`.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3551

Differential Revision: https://secure.phabricator.com/D8819
2014-04-20 11:54:50 -07:00
epriestley
5570ec5156 Rename Releeph "Project" PHID type to "Product"
Summary: Ref T3549.

Test Plan: `grep`, loaded some pages

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3549

Differential Revision: https://secure.phabricator.com/D8811
2014-04-18 17:52:45 -07:00
epriestley
35df988036 Use standard UI elements to render pull requests in Releeph
Summary:
Ref T3718. Ref T3644. Ref T3092. Switches from the Releeph UI elements to standard ones. I'll attach some screenshots.

Also fixes CSRF against the request action endpoint.

Test Plan:
  - Viewed request details.
  - Took actions on a request from detail page.
  - Viewed request list.
  - Took actions on a request from list page.
  - Used keyboard shortcuts to navigate list.
  - Used keyboard shortcuts to take actions.
  - Simulated errors.
  - Viewed on devices.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: grp, FacebookPOC, mattlqx, tala, beng, LegNeato, epriestley

Maniphest Tasks: T3718, T3092, T3644

Differential Revision: https://secure.phabricator.com/D8771
2014-04-18 06:44:45 -07:00
epriestley
f4c8a34abe Remove several "loadArcanistProject()" methods
Summary:
Ref T3551. Releeph has old-style `loadX()` methods; get rid of one of them.

Differential has a couple of copies of this too, clean them up.

Test Plan:
  - Viewed various differential revisions (with and without projects).
  - Viewed and edited Releeph products.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3551

Differential Revision: https://secure.phabricator.com/D8768
2014-04-14 12:07:32 -07:00
epriestley
05e30a024d Unban releeph product name "branch"
Summary:
Fixes T3657. We no longer construct ambiguous URIs, so product names are no longer restricted.

Also fix some minor URI construction stuff.

Test Plan: Created a product called "branch".

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3657

Differential Revision: https://secure.phabricator.com/D8767
2014-04-14 12:07:14 -07:00
epriestley
6deab24475 Remove ReleephProjectController
Summary:
Ref T3657. General changes here:

  - Removes `ReleephProjectController`, which is the source of T3657.
  - Mostly moves requests from "RQ" as a monogram to "Y" (looks like a merge, mnemonic for "yank"?, we don't have too many characters left). This should be essentially only cosmetic. This reduces ambiguity with "rQ" and "R123", which are current and future repository monograms. This will continue in the next few diffs.
  - Makes requests implement policies correctly.

Test Plan: Created, edited, browsed requests.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3657

Differential Revision: https://secure.phabricator.com/D8766
2014-04-14 12:06:56 -07:00
epriestley
2712091a71 Move Releeph branch controllers toward a modern/stable state
Summary:
Ref T3644. Ref T3657. Ref T3549. Basically:

  - Move these controllers to modern query/policy infrastructure.
  - Move them to consistent, ID-based URIs.
  - Rename "Project" to "Product"; "Pick Request" to "Pull Request".
  - Clean up a few UI things here and there.

Test Plan:
  - Created and edited branches.
  - Opened and closed branches.
  - Viewed branch history.
  - Searched within a branch.
  - Browsed to branches from products.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3644, T3549, T3657

Differential Revision: https://secure.phabricator.com/D8646
2014-04-12 16:53:51 -07:00
epriestley
c7bcecb9b0 Use ApplicationTransactions for Releeph product activity
Summary:
Ref T3549. Ref T3663.

  - Use transactions for activate/deactivate.
  - Rename some "project" -> "product".

Test Plan:
  - Activated products.
  - Deactivated products.

{F135480}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3663, T3549

Differential Revision: https://secure.phabricator.com/D8634
2014-03-29 09:16:02 -07:00
epriestley
d3dbbec88d Rename Releeph "Project" transactions to "Product"
Summary: Ref T3549. This table isn't written to yet; rename it and the DAOs and modernize the history controller.

Test Plan: Viewed history page for a product.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3549

Differential Revision: https://secure.phabricator.com/D8633
2014-03-29 09:15:09 -07:00
epriestley
ce5714526a Remove Releeph "Authors" rules
Summary:
Fixes T3659. Releeph has some awkward complexity around who ends up as a commit author. Instead, we should always try to use the original author.

Metadata (like the requestor's identity) should be accessed via Conduit or other channels instead.

Test Plan: Saved some projects, grepped for all related symbols.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T3659

Differential Revision: https://secure.phabricator.com/D8630
2014-03-29 09:14:08 -07:00
epriestley
4f26b8ffcf Remove "Release Counter" from Releeph
Summary: Fixes T3658. This field doesn't make much sense and doesn't appear to ever have actually been implemented. Particularly, the `%N` pattern doesn't actually work and I can't find anything which actually calls this stuff or exposes it externally. Facebook doesn't use it (see T3658) and I don't think it's useful in general.

Test Plan: Used `grep` to look for stuff, edited a project.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T3658

Differential Revision: https://secure.phabricator.com/D8628
2014-03-29 09:13:45 -07:00
Joshua Spence
6270114767 Various linter fixes.
Summary:
- Removed trailing newlines.
- Added newline at EOF.
- Removed leading newlines.
- Trimmed trailing whitespace.
- Spelling fix.
- Added newline at EOF

Test Plan: N/A

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley

CC: hach-que, chad, Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D8344
2014-02-26 12:44:58 -08:00
Scott MacVicar
4d1709651e [releeph] Conduit failure with bad IDs
Summary:
Instead of returning a blank result it throws exceptions. Fix this up a
little so we get some consistency with differential

Test Plan:
Loaded a bad phid for releeph, returns empty list.
Try a good phid and get 2 releeph merges.

Reviewers: epriestley, elenaperezrioja, dschleimer, #blessed_reviewers

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7302
2013-10-14 16:07:17 -07:00
epriestley
073cb0e78c Make PhabricatorPolicyInterface require a getPHID() method
Summary:
Ref T603. This cleans up an existing callsite in the policy filter, and opens up some stuff in the future.

Some policy objects don't have real PHIDs:

  PhabricatorTokenGiven
  PhabricatorSavedQuery
  PhabricatorNamedQuery
  PhrequentUserTime
  PhabricatorFlag
  PhabricatorDaemonLog
  PhabricatorConduitMethodCallLog
  ConduitAPIMethod
  PhabricatorChatLogEvent
  PhabricatorChatLogChannel

Although it would be reasonable to add real PHIDs to some of these (like `ChatLogChannel`), it probably doesn't make much sense for others (`DaemonLog`, `MethodCallLog`). Just let them return `null`.

Also remove some duplicate `$id` and `$phid` properties. These are declared on `PhabricatorLiskDAO` and do not need to be redeclared.

Test Plan: Ran the `testEverythingImplemented` unit test, which verifies that all classes conform to the interface.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7306
2013-10-14 14:35:47 -07:00
epriestley
2e5ac128b3 Explain policy exception rules to users
Summary:
Ref T603. Adds clarifying text which expands on policies and explains exceptions and rules. The goal is to provide an easy way for users to learn about special policy rules, like "task owners can always see a task".

This presentation might be a little aggressive. That's probably OK as we introduce policies, but something a little more tempered might be better down the road.

Test Plan: See screenshot.

Reviewers: btrahan, chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7150
2013-09-27 08:43:41 -07:00
epriestley
9b3d7b0dba Make most Differential reads policy-aware
Summary: Ref T603. Makes the majority of reads policy aware (and pretty much all the important ones).

Test Plan:
  - Created a comment with `differential.createcomment`.
  - Created a new revision with `arc diff` in order to exercise `differential.creatediff`.
  - Created an inline comment with `differential.createinline`.
  - Added a comment to a revision.
  - Edited an inline comment.
  - Edited a revision.
  - Wrote "Depends on ..." in a summary, saved, verified link was created.
  - Browsed a file in Diffusion.
  - Got past the code I changed in the Releeph request thing.
  - Edited a Releeph request.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7136
2013-09-26 12:37:19 -07:00
epriestley
c467cc464f Make most repository reads policy-aware
Summary: Ref T603. This swaps almost all queries against the repository table over to be policy aware.

Test Plan:
  - Made an audit comment on a commit.
  - Ran `save_lint.php`.
  - Looked up a commit with `diffusion.getcommits`.
  - Looked up lint messages with `diffusion.getlintmessages`.
  - Clicked an external/submodule in Diffusion.
  - Viewed main lint and repository lint in Diffusion.
  - Completed and validated Owners paths in Owners.
  - Executed dry runs via Herald.
  - Queried for package owners with `owners.query`.
  - Viewed Owners package.
  - Edited Owners package.
  - Viewed Owners package list.
  - Executed `repository.query`.
  - Viewed "Repository" tool repository list.
  - Edited Arcanist project.
  - Hit "Delete" on repository (this just tells you to use the CLI).
  - Created a repository.
  - Edited a repository.
  - Ran `bin/repository list`.
  - Ran `bin/search index rGTESTff45d13dffcfb3ea85b03aac8cc36251cacdf01c`
  - Pushed and parsed a commit.
  - Skipped all the Drydock stuff, as it it's hard to test and isn't normally reachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D7132
2013-09-25 16:54:48 -07:00
Bob Trahan
ea0dc5625d Purge loadRelativeEdges
Summary:
Fixes T3821. Maybe. The existing code seemed to have a bug and actually return the //commit phid//. Judging by the function name this is not intended.

Also, sorry to step on toes here -- I thought no one was assigned and was curious about loadRelativeEdges and here we are...

Test Plan: lots of logic here as I have no idea how to use Releeph.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Maniphest Tasks: T3821

Differential Revision: https://secure.phabricator.com/D6967
2013-09-13 11:40:52 -07:00
Bob Trahan
b902005bed Kill PhabricatorObjectDataHandle
Summary: Ref T603. Killing this class is cool because the classes that replace it are policy-aware. Tried to keep my wits about me as I did this and fixed a few random things along the way. (Ones I remember right now are pulling a query outside of a foreach loop in Releeph and fixing the text in UIExample to note that the ace of hearts if "a powerful" card and not the "most powerful" card (Q of spades gets that honor IMO))

Test Plan: tested the first few changes (execute, executeOne X handle, object) then got real mechanical / careful with the other changes.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran, FacebookPOC

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D6941
2013-09-11 12:27:28 -07:00
Gareth Evans
fcba0c74d9 Replace all "attach first..." exceptions with assertAttached()
Summary:
Ref T3599
Go through everything, grep a bit, replace some bits.

Test Plan: Navigate around a bit

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Maniphest Tasks: T3599

Differential Revision: https://secure.phabricator.com/D6871
2013-09-03 06:02:14 -07:00
epriestley
f034fd80db Remove getApplicationObjectTypeName from ApplicationTransactions
Summary:
We can get this out of PHIDType reasonably in all cases and simplify implementation here.

None of these translate correctly anyway so they're basically debugging/development strings.

Test Plan: `grep`, browsed some transactions

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D6786
2013-08-21 12:32:06 -07:00
epriestley
596a531ed6 Remove ReleephEvent
Summary:
Ref T3663. This is a proto-transaction record which is obsoleted by real transactions. It has no UI, so I'm not bothering to retain/migrate the data since there's no regression.

Just get rid of it and all its writers. I'm keeping the table for now in case something crazy uses this somehow, so no data is actually destroyed.

Test Plan: `grep`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3663

Differential Revision: https://secure.phabricator.com/D6784
2013-08-21 12:32:04 -07:00
epriestley
d243c30190 Remove ReleephRequestException
Summary: This has two use sites and no special logic.

Test Plan: `grep`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D6783
2013-08-21 12:32:02 -07:00
epriestley
49e0aa203c Add storage for Releeph project and branch transactions
Summary: Ref T3663. Does what it says on the tin.

Test Plan: Ran `storage upgrade`.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3663

Differential Revision: https://secure.phabricator.com/D6778
2013-08-21 12:31:51 -07:00
epriestley
973bb0c76e Remove ReleephRequestEvent
Summary: Ref T3663. This is obsolete code which is used only in this migration, which Facebook has already performed and which isn't relevant for any other installs.

Test Plan: `grep`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3663

Differential Revision: https://secure.phabricator.com/D6777
2013-08-21 12:31:50 -07:00
epriestley
dcec8e60cc Move edit/deactivate operations onto project view page in Releeph
Summary:
Ref T3092.

Releeph's objects basically go like this:

  - At the top level, we have Projects (like "www" or "libphutil")
  - Each project has Branches (like "LATEST" or "v1.1.3")
  - Each branch has Requests (like pull requests, e.g. "please merge commit X into branch Y (in project Z)")

Currently, there's no real "project detail" or "branch detail" page. Instead, we have a search results page for their contained objects. That is, the "project detail" page shows a list of branches in the project, using ApplicationSearch.

This means that operations like "edit" and "deactivate" are one level up, on the respective list pages.

Instead, move details onto the detail pages. This gives us more room for actions and information, and simplifies the list views.

Basically, these are "detail pages" where the object content is a search interface. We do something simliar to this in Phame right now, although it's messier there (no ApplicationSearch yet).

@chad, you might have some ideas here. Roughly, the design question is "How should we present an object's detail view when its content is really a search interface (Phame Blog for Posts, Releeph Project for Branches)?"

I think the simple approach I've taken here (see screenshot) gives us reasonable results, but overall it's something we haven't done much or done too much thinking about, I think.

Test Plan: {F54774}

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Maniphest Tasks: T3092

Differential Revision: https://secure.phabricator.com/D6771
2013-08-19 18:30:30 -07:00
epriestley
f7b289e3a4 Make ReleephRequest implement PhabricatorCustomFieldInterface
Summary: Ref T3718. Doesn't do anything yet.

Test Plan: Viewed and edited a request.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3718

Differential Revision: https://secure.phabricator.com/D6753
2013-08-14 12:34:10 -07:00
epriestley
74de24909b Partially move Releeph custom fields to PhabricatorCustomField
Summary:
Fixes T3661. Ref T3718. This makes Releeph custom fields extend PhabricatorCustomField so we can start moving over other pieces of infrastructure (rendering, storage, etc) to run through the same pathways. It's roughly the minimum amount of work required to be able to move forward.

NOTE: This removes per-project custom field selectors. Fields are now configured for an entire install. My understanding is that Facebook does not use this feature, and modern field infrastructure has moved away from selectors.

Test Plan: Viewed and edited projects, branches, and requests in Releeph. Grepped for removed config. Grepped for `field_selector`.

Reviewers: btrahan

Reviewed By: btrahan

CC: LegNeato, aran

Maniphest Tasks: T3661, T3718

Differential Revision: https://secure.phabricator.com/D6750
2013-08-14 12:34:07 -07:00
epriestley
9f41032693 Remove "cut point commit identifier" from Releeph
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
2013-08-14 09:01:38 -07:00
epriestley
a84cc777c8 Remove "Project ID" from Releeph Projects
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
2013-08-14 09:00:56 -07:00
epriestley
296818e129 Remove ReleephProject->repositoryID writes
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
2013-08-14 09:00:25 -07:00
epriestley
a7955e919c Remove all reads of ReleephProject->repositoryID
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
2013-08-14 08:59:28 -07:00
epriestley
ece246cb72 Modernize Releeph Request create/edit controller
Summary: Ref T3092.

Test Plan: Created a new pick request. Edited an existing pick request.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3092

Differential Revision: https://secure.phabricator.com/D6630
2013-07-30 12:38:32 -07:00
epriestley
d2e5afb095 Use application PHIDs in Releeph, plus more
Summary:
Ref T2715. Ref T3551. Ref T603. This does a few things, but they're all sort of small:

  - We commonly use a `getX()` / `attachX()` pattern, but have very similar code in the `getX()` method every time. Provide a convenience method to make this pattern easier to write.
  - We use `willFilterPage()` in many queries, but it currently is called with zero or more results. This means we have a lot of "if no results, return nothing" boilerplate. Make it call only for one or more results.
  - Implement `PhabricatorPolicyInterface` on `ReleephBranch`. A branch has the same policy as its project.
  - Implement `ReleephBranchQuery`.
  - Move the branch PHID type to application PHID infrastructure.

Test Plan: Browsed Releeph. Used `phid.query` to query branch PHIDs.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T603, T2715, T3551

Differential Revision: https://secure.phabricator.com/D6512
2013-07-22 12:17:32 -07:00
epriestley
f2ed56147d Use application handle infrastructure for Releeph Requests and Releeph Projects
Summary: Ref T2715.

Test Plan: Used `phid.query` to query handles. Browsed Releeph.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2715

Differential Revision: https://secure.phabricator.com/D6510
2013-07-22 12:17:30 -07:00
Edward Speyer
4692920751 Releeph: use relative URIs
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
2013-05-22 15:42:30 +01:00
elenaperezrioja
af220fddc1 Add get Releeph Requests conduit method
Summary: Added "getrequests" conduit method

Test Plan: Open /conduit/method/differential.getrequests/ and try different inputs.

Reviewers: edward, epriestley

Reviewed By: edward

CC: aran, epriestley, Korvin

Maniphest Tasks: T3057

Differential Revision: https://secure.phabricator.com/D5788
2013-05-14 09:50:23 -07:00
Edward Speyer
da92d79d8d ReleephRequestStatus
Summary: This is just a bit of gardening in order to make the responsive-UI diff easier; I'll be putting `getColorFor($status)` type things in this class, following the pattern in `ManiphestTaskStatus`.

Test Plan: Poke around Releeph.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D5893
2013-05-11 15:20:16 +01:00
Edward Speyer
fcb7286533 ReleephRequest xactions
Summary:
Migrate to `PhabricatorApplicationTransactions` (`ReleephRequestTransactions` applied by `ReleephRequestTransactionalEditor`, instead of `ReleephRequestEvents` created by `ReleephRequestEditor`) and migrate all the old events into transactions.  Email is supported in the standard way (no more `ReleephRequestMail`) as well.

This also collapses the Releeph request create and edit controllers into one class, as well as breaking everyone's subject-based mail rules by standardising them (but which should be more easily filtered by looking at headers.)

Test Plan:
* Make requests, then pick them.
* Pick and revert the same request so that discovery happens way after `arc` has told Releeph about what's been happening.
* Try to pick something that fails to pick in a project with pick instructions (and see the instructions are in the email.)
* Load all of FB's Releeph data into my DB and run the `storage upgrade` script.
* Request a commit via the "action" in a Differential revision.

Reviewers: epriestley

Reviewed By: epriestley

CC: epriestley, aran, Korvin, wez

Maniphest Tasks: T3092, T2720

Differential Revision: https://secure.phabricator.com/D5868
2013-05-11 15:20:09 +01:00
Edward Speyer
961c2c0108 Releeph s/isPusher/isAuthoritative/
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
2013-05-09 17:55:40 +01:00
Edward Speyer
58f0f37873 Add mail keys to ReleephRequests
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
2013-05-08 10:38:07 +01:00
Edward Speyer
5b2fc6a184 Simplify ReleephRequest schema
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
2013-05-08 10:27:20 +01:00
Edward Speyer
55c3c6cb12 Some ReleephRequests don't have diffs
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
2013-05-07 11:13:22 +01:00
Edward Speyer
5c4a9ac9e5 Use LiskDAOSet's loadRelativeEdges with ReleephRequest
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
2013-05-07 11:05:18 +01:00