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

177 commits

Author SHA1 Message Date
epriestley
efcca310c2 In Differential mail, hide "summary" if empty and show "test plan" if nonempty
Summary:
Ref T4481. Summary is optional, but we currently always render it.

We previously rendered TEST PLAN. I wanted to see if anyone missed it. I miss it a little bit, and it sounds like @spicyj misses it. Restore it.

Test Plan:
  $ ./bin/mail show-outbound --id 15232
  ...
  BODY
  epriestley created this revision.
  epriestley added reviewers: The Bureaucracy, duck.
  epriestley added a subscriber: duck.

  TEST PLAN
    more j

  REVISION DETAIL
    http://local.aphront.com:8080/D1042

  AFFECTED FILES
    number_j.txt

  CHANGE DETAILS
    Index: number_j.txt
    ===================================================================
    --- number_j.txt
    +++ number_j.txt
    @@ -137,3 +137,4 @@
     j
     j
     j
    +j

  To: epriestley, duck, Sebastiangarcia, Ahmedsmoore, nathanhthomas, chewnicorn
  Cc: duck

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley, spicyj

Maniphest Tasks: T4481

Differential Revision: https://secure.phabricator.com/D8531
2014-03-14 11:53:06 -07:00
epriestley
b168ee116b Fix "Send an email to" Herald rule for Differential
Summary: Herald returns a map of `phid => true`. This is unintuitive and should probably be cleaned up eventually.

Test Plan: With a "Send an email to" rule, updated a revision and saw no error in error log.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8527
2014-03-14 11:52:16 -07:00
epriestley
3b861ab741 Fix two transactional issues around revision status
Summary:
Two issues:

  - Herald is currently overwriting accepts and rejects with "blocking reviewer". Just stop it from doing that.
  - When you update an accepted revision, we put it back in "needs review", then return it to "accepted", generating an extra transaction. Instead, don't.

Test Plan:
  - Updated a revision with an accepting, herald-based blocking project reviewer. Reviewer was still accepting.
  - Updated an accepted revision, didn't get an extra transaction.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8506
2014-03-12 15:24:43 -07:00
epriestley
08d013b391 Minor, fix parameter passed to HarbormasterBuildable::applyBuildPlans()
Summary: This should be a PHID, not an object.
2014-03-12 12:13:54 -07:00
epriestley
9e3baacc95 Restore old "author can not be a reviewer" rule to Transactions
Summary:
This is a bit messy, but not tooo bad:

  - In general, stop the author from being added as a reviewer.
  - In the specific case that "self accept" is enabled, allow it. This is easier than trying to special case it.
  - When commandeering, we make the author a reviewer and make the actor the author, but these happen after validation. At validation time, it looks like we're making the author a reviewer. Just special case this.
  - Provide a slightly nicer message when trying to add yourself from `arc`. We hit the Transactions message anyway, but it's not formatted as cleanly.
  - Don't try to add the author via Herald.

Test Plan:
  - Edited a revision with author = reviewer, got stopped.
  - Commandeered revision.
  - Updated from `arc`.
  - Updated in general.
  - Fired a "add author as reviewer" Herald rule without things breaking.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8496
2014-03-12 06:04:30 -07:00
epriestley
95285aee50 When creating a new revision, include the summary in the initial email
Summary: This got dropped in the ApplicationTransactions stuff.

Test Plan: Created a new revision.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8495
2014-03-11 17:13:00 -07:00
epriestley
0b15624c37 Fix two minor Differential issues
Summary: The JIRA field is currently always enabled. This isn't correct; it
should be disabled if there's no JIRA provider.

We also use the old set of reviewers to compute mail delivery. Instead, reload
the correct set of reviewers before moving on after finalizing transactions.
2014-03-11 13:50:13 -07:00
epriestley
9e8bbdb3a2 Port Differential mail features forward to transactions
Summary:
Ref T2222. Brings the major mail features (affected files, patches) forward.

This drops some of the minor integrations which just show object state (like "Maniphest Tasks") since I think they're not very important. I'll put them back if users miss them.

Test Plan: Sent mail with inline/attached patches.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8459
2014-03-11 13:02:06 -07:00
epriestley
1df84168ef Remove DifferentialRevisionEditor
Summary: Ref T2222. This has no callsites and no functionality not present in the TransactionEditor.

Test Plan: awwyiss

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8456
2014-03-11 13:02:04 -07:00
epriestley
c68703fbcb Perform derived index updates in TransactionEditor
Summary: Ref T2222. We have two tables (one for hashes; one for paths) which were unevenly updated before. Now, update them consistently in the TransactionEditor.

Test Plan: Created a revision, saw it populate this information.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8455
2014-03-11 13:02:03 -07:00
epriestley
a19f49632f Remove willWriteRevision/didWriteRevision hooks
Summary:
Ref T2222. DifferentialRevisionEditor has no remaining callsites, but it has a bit of functionality which still needs to be ported forward. I'm going to rip it apart piece by piece.

This removes the willWriteRevision/didWriteRevision hooks. They are completely encapsulated by transactions now, except for a unique piece of branch/task logic, which I migrated forward.

Test Plan:
  - Lots of `grep`.
  - Created a new revision on branch `T25`, saw it associate with the task.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8454
2014-03-11 13:02:01 -07:00
epriestley
fbaa12440e Use DifferentialRevisionEditor in lipsum
Summary: Ref T2222.

Test Plan: Generated revisions with `bin/lipsum`.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8453
2014-03-11 13:02:00 -07:00
epriestley
314edcabbb Fix Herald adapter construction for new revisions. Fixes T4572. 2014-03-08 06:35:41 -08:00
epriestley
f25cce1e69 Remove DifferentialCommentEditor and DifferentialCommentMail
Summary: Ref T2222. These no longer have any callsites. Also got rid of a little bit of other code which also no longer has callsites.

Test Plan: `grep`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8443
2014-03-07 17:44:19 -08:00
epriestley
b04f706c0a Use TransactionEditor when closing revisions in response to commits
Summary: Ref T2222. When we discover a commit associated with a revision, close it using modern transactions.

Test Plan: {F123848}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8441
2014-03-07 17:43:58 -08:00
epriestley
2ceffadee7 Support Herald rules for new Differential edits
Summary:
Ref T2222. Ref T4484. See D8404 for discussion.

When a revision is updated with the new Editor, apply Herald rules. Additionally, apply them in a modern way which generates transactions.

Test Plan: {F122299}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T2222, T4484

Differential Revision: https://secure.phabricator.com/D8405
2014-03-05 12:07:13 -08:00
epriestley
4ef87eeac8 Add an explcit "Changes Planned" state for Differential
Summary: Ref T2222. Ref T4481. This fixes the issue where "Plan Changes" could immediately trigger a state change (e.g., back to accepted) because of state-based transitions out of the NEEDS_REVISION state.

Test Plan: Planned changes an "accepted" revision, it didn't immediately return to being accepted.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222, T4481

Differential Revision: https://secure.phabricator.com/D8403
2014-03-05 10:47:47 -08:00
epriestley
9da6ec2081 Make updates of rejected revisions behave correctly again
Summary:
Ref T2222. Ref T4481. Specifically:

  - When a revision is updated, change all "Reject" reviewers to "Reject Prior".
  - Change status to "Needs Review".
  - Update the state logic to account for this properly.

Test Plan:
  - Created a revision as user A, with B as a reviewer.
  - Rejected as B.
  - Updated the revision as A.
  - Saw revision in "needs review" state, with B as a "Rejected Prior" reviewer.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4481, T2222

Differential Revision: https://secure.phabricator.com/D8402
2014-03-05 10:47:29 -08:00
Bob Trahan
e78df59ced Maniphest Tasks + Project Boards - some polish
Summary:
Fixes T4550 by changing supportsFeed to shouldPublishFeedStory, so things can be more granular like that are with mail. Attempts to fix things generally too, filtering out xactions that have no business in feed, etc.

Also return an updated Task HTML representation on drag and drop moves, etc. This is important so if the priority changes you can see it reflected in the UI.

Test Plan: dragged tasks around. observed no feed stories on subpriority drags. observed feed stories and updated color bars on stories that changed priority

Reviewers: epriestley, chad

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Maniphest Tasks: T4550

Differential Revision: https://secure.phabricator.com/D8399
2014-03-04 17:01:33 -08:00
epriestley
83206242c9 Clean up some Differential behaviors
Summary:
Ref T2222.

  - Restore mail tags for ApplicationTransactions mail.
  - Restore subject line verbs.
  - Denormalize line count and repository PHID.
  - Fix an issue with the mailgun adapter where headers weren't attached properly.

Test Plan: Sent some mail, verified it had correct subjects and tags.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8378
2014-03-03 08:36:40 -08:00
epriestley
bca0ad8fdd Make "EditPro" controller work with diff updates
Summary:
Ref T2222. Make the "EditPro" controller accommodate diff updates, and support the transaction type. This one is pretty straightforward.

Also make `revisionPHID` in the comments table nullable to fix the "Edit" action.

Test Plan:
  - Created new revision.
  - Updated revision.
  - Tried to do some invalid stuff.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8376
2014-02-28 16:49:22 -08:00
epriestley
8e32ab88c4 Minor, fix a missing parameter. 2014-02-28 15:25:49 -08:00
epriestley
11c1edfb74 Implement "words of power" against ApplicationTransactions
Summary:
Ref T2222. Differential has certain "words of power" (like `Ref T123` or `Depends on D345`) which should expand into a separate transaction when they appear anywhere in text.

Currently, they're respected in only some fields. I'm expanding them to work in any remarkup field, including comments and inline comments.

This partially generalizes transaction expansion/extraction in comments. Eventually, I'll probably implement some very soft sort of reference edge for T4036, maybe.

Test Plan: {F119368}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8369
2014-02-28 15:20:45 -08:00
epriestley
647d52f248 Improve threading of new and old Differential mail
Summary: Ref T2222. This should help new mail thread properly with old mail.

Test Plan: Will push.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8367
2014-02-27 15:16:22 -08:00
epriestley
ba7d67f917 Use "CommentPro" controller instead of "Comment" controller
Summary: Ref T2222. This will probabaly have a few rough edges too, but seems to work well.

Test Plan:
  - Made a bunch of comments while building this.
  - Made some new comments.
  - Verified that the Asana/JIRA integration is only a little bit janky, not completely broken.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8362
2014-02-27 11:06:55 -08:00
epriestley
cce67caa0f Fix bad method call from CustomField migration
Fixes T4480.
2014-02-27 09:16:50 -08:00
epriestley
cd7171ec6e Migrate old AuxiliaryField storage to modern CustomField storage
Summary: Ref T2222. Ref T3886. Differential has a legacy storage table for auxiliary fields; move the data to modern storage.

Test Plan:
  - Ran migration.
  - Verified fields still worked properly afterward (view, edit, etc).

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3886, T2222

Differential Revision: https://secure.phabricator.com/D8355
2014-02-26 16:52:30 -08: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
epriestley
424ba2e588 Render inline comments in "Pro" mail
Summary: Ref T2222. This enriches mail a little bit to get these rendering pretty much like they do now.

Test Plan: {F118255}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8343
2014-02-25 15:29:10 -08:00
epriestley
06fc82a3ee Mark reviewers as "commented" when they leave a comment
Summary:
Ref T2222. This requires one new trick:

  - When merging edge transactions which both add/update an edge, the Editor gets to control how the edge data is merged.

Specifically, we pick the "strongest" state to keep, so "accept + comment" leaves you with an accept instead of a comment.

Test Plan: Accepted, commented on, and comment + accepted revisions. Added some debugging dumps to verify that the merging was getting hit and working correctly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8340
2014-02-25 12:37:11 -08:00
epriestley
a69cca9fbb Update overall revision status after reviewers change
Summary:
Ref T2222. This doesn't feel super clean, but doesn't feel too bad either.

Basically, Differential transactions can have secondary state-based effects (changing the overall revision status) when reviewers resign, are removed, accept, or reject revisions.

To deal with this in ApplicationTransactions, I did this:

  - `applyFinalEffects()` can now alter the transaction set (notably, add new ones). This mostly matters for email, notifications and feed.
  - In Differential, check for an overall revision state transition in `applyFinalEffects()` (e.g., your reject moving the revision to a rejected state).
  - I'm only writing the transaction if the transition is implied and indirect.
    - For example, if you "Plan Changes", that action changes the state on its own so there's no implicit state change transaction added.

The transactions themselves are kind of fluff, but it seems useful to keep a record of when state changes occurred in the transaction log. If people complain we can hide/remove them.

Test Plan: {F118143}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8339
2014-02-25 12:36:49 -08:00
epriestley
ca8c2c2d11 Implement Accept/Reject in ApplicationTransactions, approximately
Summary: Ref T2222. This mostly makes Accept/Reject work. The big missing piece is that overall revision status does not yet update properly. I need to think about how I want that to work a little bit more.

Test Plan: Accepted and rejected some stuff.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8333
2014-02-25 12:36:39 -08:00
epriestley
d07292df7f Implement Commandeer action in ApplicationTransactions
Summary: Ref T2222. Implements Commandeer on the new stuff.

Test Plan:
{F117768}

{F117769}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8331
2014-02-25 12:36:24 -08:00
epriestley
0f0673b9e5 Remove "dateCommitted" field from DifferentialRevision
Summary: Ref T2222. This is obsolete and no longer used. We could deduce it from transactions or commits in modern Phabricator if we wanted it. We may implement a more general mechanism for T4434.

Test Plan: `grep`

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8330
2014-02-25 12:36:14 -08:00
epriestley
9292433dae Implement "Resign" action against ApplicationTransactions
Summary:
Ref T2222. This introduces two small new concepts:

  - `expandTransactions()`: allows a transaction to expand into several transactions. For example, "resign" adds a "remove reviewers" transaction.
    - We have some other cases which could use this, but currently hard-code things outside of the `Editor`.
      - One example is that in Maniphest, closing a task implies claiming it if it is unowned.
  - `setIgnoreOnNoEffect()`: The whole Editor can be set to continue or stop if any transactions have no effect, but this allows the behavior to be refined at the individual transaction level. This is primarily to make the UX less confusing, so the user gets only a single relevant error instead of one for each expanded transaction.

Otherwise, this is pretty straightforward.

Test Plan:
Rigged comment form to use SavePro controller, enabled resign action, then tried to resign from a bunch of stuff.

{F117743}

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8328
2014-02-25 12:36:02 -08:00
epriestley
4eadcf975a Implement most Differential actions against ApplicationTransactions
Summary: Ref T2222. Implements the simpler actions (abandon, reclaim, close, reopen, plan changes, request review) in a transactional way with validation and effect checks.

Test Plan:
  - Rigged submissions to point at the Pro controller.
  - Rigged dropdown to have all these options all the time.
  - Tried to apply about 20-30 of these operations to various revisions and always got the expected result (success, error, or no-op).

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8307
2014-02-24 15:57:49 -08:00
epriestley
d48a88d4cd Add inline comment support to "Pro" comment save controller
Summary: Ref T2222. Makes the "pro" controller work with inlines.

Test Plan: Added a bunch of inlines and saved them with the "pro" controller.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8306
2014-02-24 15:57:35 -08:00
epriestley
c7d208fda1 Add a "Pro" version of the Differential comment save controller
Summary: Ref T2222. Adds a mostly-functional "Pro" comment controller. This does the core stuff, but does not yet do actions (accept, reject, etc.) or inline comments.

Test Plan: Changed the `if (false)` to an `if (true)`, then made some comments, etc. This is normally unreachable.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8304
2014-02-24 15:57:26 -08:00
epriestley
3a8eb28a07 Send basic email from new ApplicationTransaction editor
Summary: Ref T2222. Adds basic support for email.

Test Plan: Received an email via `/editpro/`.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8303
2014-02-24 15:57:16 -08:00
epriestley
c5ba75ee9e Implement a "Reviewers" CustomField
Summary:
Ref T3886:

  - Adds a "Reviewers" field as a modern CustomField.

Ref T418:

  - Allows CustomFields to emit transaction metadata.

Test Plan: {F116254}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T418, T3886

Differential Revision: https://secure.phabricator.com/D8291
2014-02-21 11:54:32 -08:00
epriestley
aa7ba4c6e6 Implement Differential subscribers as a CustomField
Summary: Ref T3886. Now that a custom field can emit a core transaction, just emit a subscribers transaction.

Test Plan: {F116014}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3886

Differential Revision: https://secure.phabricator.com/D8289
2014-02-21 11:54:08 -08:00
epriestley
f91e94eb90 Implement view and edit policies in Differential CustomFields
Summary:
Ref T3886. Ref T418.

  - Adds "View Policy" and "Edit Policy" fields.
  - Allows CustomFields to produce arbitrary types of transactions, so these fields can produce standard view/edit policy transactions and get all the strings and validation associated with them.

Test Plan: {F116001}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T418, T3886

Differential Revision: https://secure.phabricator.com/D8287
2014-02-21 11:53:48 -08:00
epriestley
92ac8b5ad9 Make Differential inline comment rendering more consistent and somewhat more modern
Summary: Ref T2222. Ref T1790. I partially modernized this recently, but bring it to the mail version too.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: zeeg, aran

Maniphest Tasks: T1790, T2222

Differential Revision: https://secure.phabricator.com/D8294
2014-02-21 11:52:03 -08:00
epriestley
65bc2b1ac5 Implement "Pro" version of revision editor, with one field
Summary:
Ref T3886. I spent a few hours trying to make `DifferentialFieldSpecification` extend `PhabricatorCustomField` so I could be more blunt in my approach here and just swap the whole thing over in one go (more or less like I did with Maniphest) but we have a ton of custom fields and things felt really shaky and the change was enormous and hard to keep track of.

Instead, I'm going to do this more gradually and go field-by-field. This implements a CustomField version of the "Title" field.

(There are no links to this in the UI.)

Test Plan:
{F115353}

{F115354}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3886

Differential Revision: https://secure.phabricator.com/D8276
2014-02-18 16:32:55 -08:00
epriestley
7374a0a4d4 Fix inline comment links for non-visible comments
Summary: Ref T2222. Restore this funky is-visible / inline-is-elsewhere logic.

Test Plan: Updated a revision, saw all the inlines render properly when looking at various diffs and versus-diffs. Clicked inline links.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8224
2014-02-13 16:52:48 -08:00
epriestley
0dc73d5d93 Always provide a valid content source for DifferentialCommentEditor
Summary: Ref T2222. On the `tmp.differential` branch, we're currently having
issues parsing commits which reference Differential revisions, because the
"user closed this revision (closed by commit xyz)" message is fataling:

  [2014-02-13 14:12:36] EXCEPTION: (PhutilProxyException) Error while
  executing task ID 345358 from queue. {>} (AphrontQueryException)
  #1048: Column 'contentSource' cannot be null

Specifically, the MessageParser pathway for CommentEditor doesn't set a content
source. Make sure CommentEditor always sets a content source.

(This is also causing a buildup of diffs on D8212 and D8211.)

Auditors: btrahan
2014-02-13 06:19:55 -08:00
epriestley
18938b5310 Migrate Differential comments to ApplicationTransactions
Summary:
Ref T2222. This is the big one.

This migrates each `DifferentialComment` to one or more ApplicationTransactions (action, cc, reviewers, update, comment, inlines), and makes `DifferentialComment` a double-reader for ApplicationTransactions.

The migration is pretty straightforward:

  - If a comment took an action not otherwise covered, it gets an "action" transaction. This is something like "epriestley abandoned this revision.".
  - If a comment updated the diff, it gets an "updated diff" transaction. Very old transactions of this type may not have a diff ID (probably only at Facebook).
  - If a comment added or removed reviewers, it gets a "changed reviewers" transaction.
  - If a comment added CCs, it gets a "subscribers" transaction.
  - If a comment added comment text, it gets a "comment" transaction.
  - For each inline attached to a comment, we generate an "inline" transaction.

Most comments generate a small number of transactions, but a few generate a significant number.

At HEAD, the code is basically already doing this, so comments in the last day or two already obey these rules, roughly, and will all generate only one transaction (except inlines).

Because we've already preallocated PHIDs in the comment text table, we only need to write to the transaction table.

NOTE: This significantly degrades Differential, making inline comments pretty much useless (they each get their own transaction, and don't show line numbers or files). The data is all fine, but the UI is garbage now. This needs to be fixed before we can deploy this to users, but it's easily separable since it's all just display code.

Specifically, they look like this:

{F112270}

Test Plan:
I've migrated locally and put things through their paces, but it's hard to catch sketchy stuff locally because most of my test data is nonsense and bad migrations wouldn't necessarily look out of place.
IMPORTANT: I'm planning to push this to a branch and then shift production over to the branch, and run it for a day or two before bringing it to master.

I generally feel good about this change: it's not that big since we were able to separate a lot of pieces out of it, and it's pretty straightforward. That said, it's still one of the most scary/dangerous changes we've ever made.

Reviewers: btrahan

CC: chad, aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8210
2014-02-12 14:34:48 -08:00
epriestley
8f9b7f4196 Move Differential to proper subscriptions
Summary:
Ref T2222. Ref T4415. We're still writing Differential subscription stuff into this weird legacy `differential_relationship` table, which is like an edge table but extremely ancient.

Move it into a proper table.

I've removed `withSubscriptions()` from `DifferentialRevisionQuery`. It was weird, doesn't work consistently with other similar filters, and was only used by the API. Now it means "ccs", which is consistent with the ApplicationSearch UI and with Maniphest.

Test Plan:
Without migrating, added and removed subscribers via various workflows. Queried for subscribers. Everything worked as expected.

Ran the migration, verified data survived.

Reviewers: btrahan

Reviewed By: btrahan

CC: FacebookPOC, aran

Maniphest Tasks: T2222, T4415

Differential Revision: https://secure.phabricator.com/D8202
2014-02-12 08:53:40 -08:00
epriestley
1dbfc56d35 Write one DifferentialComment per CommentEditor action
Summary:
See D8200. Ref T2222. Instead of writing one comment which can have a ton of different effects, write a series of one-effect comments. These will be easier to convert into ApplicationTransactions.

This has a minor user-facing effect of making these multiple-action comments render separately:

{F111919}

Once the migration completes, they should automatically merge together nicely again.

Test Plan: Made a bunch of comments and took a bunch of actions, all of which worked normally except that they rendered as several things instead of just one.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, FacebookPOC

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8201
2014-02-11 15:21:21 -08:00
epriestley
c65fad3fca Separate revision updates into two separate comments
Summary:
Ref T2222. Instead of writing one comment which performs both a diff update and adds a comment, write two comments, one for each action. These will translate directly into ApplicationTransactions writes.

This has a small impact on the UX: these updates now render in two rows, instead of one. After T2222, they'll automerge back together.

{F111909}

Test Plan: Updated a revision.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2222

Differential Revision: https://secure.phabricator.com/D8200
2014-02-11 15:21:14 -08:00