1. 08 Feb, 2018 1 commit
    • epriestley's avatar
      Use object PHIDs for "Thread-Topic" headers in mail · f090fa74
      epriestley authored
      Summary:
      Depends on D19009. Ref T13053. For "Must Encrypt" mail, we must currently strip the "Thread-Topic" header because it sometimes contains sensitive information about the object.
      
      I don't actually know if this header is useful or anyting uses it. My understanding is that it's an Outlook/Exchange thing, but we also implement "Thread-Index" which I think is what Outlook/Exchange actually look at. This header may have done something before we implemented "Thread-Index", or maybe never done anything. Or maybe older versions of Excel/Outlook did something with it and newer versions don't, or do less. So it's possible that an even better fix here would be to simply remove this, but I wasn't able to convince myself of that after Googling for 10 minutes and I don't think it's worth hours of installing Exchange/Outlook to figure out. Instead, I'm just trying to simplify our handling of this header for now, and maybe some day we'll learn more about Exchange/Outlook and can remove it.
      
      In a number of cases we already use the object monogram or PHID as a "Thread-Topic" without users ever complaining, so I think that if this header is useful it probably isn't shown to users, or isn't shown very often (e.g., only in a specific "conversation" sub-view?). Just use the object PHID (which should be unique and stable) as a thread-topic, everywhere, automatically.
      
      Then allow this header through for "Must Encrypt" mail.
      
      Test Plan: Processed some local mail, saw object PHIDs for "Thread-Topic" headers.
      
      Reviewers: amckinley
      
      Maniphest Tasks: T13053
      
      Differential Revision: https://secure.phabricator.com/D19012
      f090fa74
  2. 09 Oct, 2017 1 commit
    • Dmitri Iouchtchenko's avatar
      Fix spelling · 9bd6a370
      Dmitri Iouchtchenko authored
      Summary: Noticed a couple of typos in the docs, and then things got out of hand.
      
      Test Plan:
        - Stared at the words until my eyes watered and the letters began to swim on the screen.
        - Consulted a dictionary.
      
      Reviewers: #blessed_reviewers, epriestley
      
      Reviewed By: #blessed_reviewers, epriestley
      
      Subscribers: epriestley, yelirekim, PHID-OPKG-gm6ozazyms6q6i22gyam
      
      Differential Revision: https://secure.phabricator.com/D18693
      9bd6a370
  3. 19 May, 2017 1 commit
    • epriestley's avatar
      Disperse task subpriorities in blocks · 1644b450
      epriestley authored
      Summary:
      Ref T7664. The current algorithm for moving task subpriorities can end up stuck in a real sticky swamp in some unusual situations.
      
      Instead, use an algorithm which works like this:
      
        - When we notice two tasks are too close together, look at the area around those tasks (just a few paces).
        - If things look pretty empty, we can just spread the tasks out a little bit.
        - But, if things are still real crowded, take another look further.
        - Keep doing that until we're looking at a real nice big spot which doesn't have too many tasks in it in total, even if they're all in one place right now.
        - Then, move 'em out!
      
      Also:
      
        - Just swallow our pride and do the gross `INSERT INTO ... "", "", "", "", "", "", ... ON DUPLICATE KEY UPDATE` to bulk update.
        - Fix an issue where a single move could cause two different subpriority recalculations.
      
      Test Plan:
        - Changed `ManiphesTaskTestCase->testTaskAdjacentBlocks()` to insert 1,000 tasks with identical subpriorities, saw them spread out in 11 queries instead of >1,000.
        - Dragged tons of tasks around on workboards.
        - Ran unit tests.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T7664
      
      Differential Revision: https://secure.phabricator.com/D17959
      1644b450
  4. 15 May, 2017 1 commit
    • Chad Little's avatar
      Update Maniphest for modular transactions · d6a620be
      Chad Little authored
      Summary: Ref T12671. This modernized Maniphest transactions to modular transactions.
      
      Test Plan:
      - Create Task
      - Edit Task
      - Raise Priority
      - Change Status
      - Merge as a duplicate
      - Create Subtask
      - Claim Task
      - Assign Project
      - Move on Workboard
      - Set a cover image
      - Assign story points
      - Change story points
      - Generate lots via lipsum
      - Bulk edit tasks
      - Leave comments
      - Award Token
      
      I'm sure I'm missing something.
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: hazelyang, Korvin
      
      Maniphest Tasks: T12671
      
      Differential Revision: https://secure.phabricator.com/D17844
      d6a620be
  5. 22 Jun, 2016 1 commit
    • epriestley's avatar
      Split "Edit Blocking Tasks" into "Edit Parent Tasks" and "Edit Subtasks" · 2cb77957
      epriestley authored
      Summary:
      Ref T11179. This splits "Edit Blocking Tasks" into two options now that we have more room ("Edit Parent Tasks", "Edit Subtasks").
      
      This also renames "Blocking" tasks to "Subtasks", and "Blocked" tasks to "Parent" tasks. My goals here are:
      
        - Make the relationship direction more clear: it's more clear which way is up with "parent" and "subtask" at a glance than with "blocking" and "blocked" or "dependent" and "dependency".
        - Align language with "Create Subtask".
        - To some small degree, use more flexible/general-purpose language, although I haven't seen any real confusion here.
      
      Fixes T6815. I think I narrowed this down to two issues:
      
        - Just throwing a bare exeception (we now return a dialog explicitly).
        - Not killing open transactions when the cyclec check fails (we now kill them).
      
      Test Plan:
        - Edited parent tasks.
        - Edited subtasks.
        - Tried to introduce graph cycles, got a nice error dialog.
      
      {F1697087}
      
      {F1697088}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T6815, T11179
      
      Differential Revision: https://secure.phabricator.com/D16166
      2cb77957
  6. 03 May, 2016 1 commit
    • epriestley's avatar
      Fix errant rules for associating projects when dragging tasks within a milestone column · cac26c88
      epriestley authored
      Summary:
      Fixes T10912. When you drag tasks within a milestone, we currently apply an overbroad, API-focused rule and add the parent board's project. This logic was added fairly recently, as part of T6027, to improve the behavior of API-originated moves.
      
      Later on, this causes the task to toggle in and out of the parent project on every alternate drag.
      
      This logic is also partially duplicated in the `MoveController`.
      
        - Add test coverage for this interaction.
        - Fix the logic so it accounts for subproject / milestone columns correctly.
        - Put all of the logic into the TransactionEditor, so the API gets the exact same rules.
      
      Test Plan:
        - Added a failing test and made it pass.
        - Dragged tasks around within a milestone column:
          - Before patch: they got bogus project swaps on every other move.
          - After patch: projects didn't change (correct).
        - Dragged tasks around between normal and milestone columns.
          - Before patch: worked properly.
          - After patch: still works properly.
      
      Here's what the bad changes look like, the task is swapping projects with every other move:
      
      {F1255957}
      
      The "every other" is because the logic was trying to do this:
      
        - Add both the parent and milestone project.
        - Whichever one exists already gets dropped from the change list because it would have no effect.
        - The other one then applies.
        - In applying, it forces removal of the first one.
        - Then this process repeats in the other direction the next time through.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10912
      
      Differential Revision: https://secure.phabricator.com/D15834
      cac26c88
  7. 06 Apr, 2016 1 commit
    • epriestley's avatar
      Merge TYPE_PROJECT_COLUMNS and TYPE_COLUMN transactions into a more general... · 86b08514
      epriestley authored
      Merge TYPE_PROJECT_COLUMNS and TYPE_COLUMN transactions into a more general TYPE_COLUMNS transaction
      
      Summary:
      Ref T6027. We currently have two different transaction types:
      
        - `TYPE_PROJECT_COLUMNS` does most of the work, but has a sort of weird structure and isn't really suitable for API use.
        - `TYPE_COLUMN` is this weird, junk transaction which mostly just creates the other transaction.
      
      Merge them into a single higher-level `TYPE_COLUMNS` transaction which works properly and has a sensible structure and comprehensive error checking.
      
      Remaining work here:
      
        - I've removed the old rendering logic, but not yet added new logic. I need to migrate the old transaction types and add new rendering logic.
        - Although the internal representation is now //suitable// for use in the API, it isn't properly exposed yet.
      
      Test Plan:
        - Created tasks into a column.
        - Ran unit tests.
        - Moved tasks between columns.
        - Will perform additional testing in followups.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T6027
      
      Differential Revision: https://secure.phabricator.com/D15634
      86b08514
  8. 23 Feb, 2016 1 commit
    • epriestley's avatar
      In Maniphest tasks, only move old owner to CC if owner changed · 0799c918
      epriestley authored
      Summary:
      Fixes T10426. When the owner of a task changes, we try to add the old owner to CC so they're kept in the loop.
      
      Currently, we do this unconditionally. This can add the owner as a subscriber when someone didn't change anything, which is confusing.
      
      Instead, only do this if the owner actually changed.
      
      Test Plan:
        - With "A" as owner, edited task and saved.
          - Before patch, A was added as subscriber.
          - After patch, A not added.
        - With "A" as owner, changed owner to "B" and saved.
          - Both before and after patch, "A" is added as a subscriber.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10426
      
      Differential Revision: https://secure.phabricator.com/D15333
      0799c918
  9. 15 Feb, 2016 1 commit
    • epriestley's avatar
      Fix an issue where newly created tasks could appear at the bottom of columns · e4690a38
      epriestley authored
      Summary:
      Ref T10349. At HEAD, if you create a task //on a board//, it floats to the top correctly.
      
      If you create a task elsewhere and tag it with the board, you were subject to the whims of the layout engine and it would generally end up on the bottom.
      
      Instead, make the rules consistent so that "virtual" positions (of tasks which haven't been committed to a particular position yet) still float to the top.
      
      Test Plan:
        - Created tasks from a board.
        - Created tasks from Maniphest, then looked at them on a board.
        - Moved tasks around.
        - In all cases, newly created tasks floated to the top.
        - Sorted by natural and priority.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10349
      
      Differential Revision: https://secure.phabricator.com/D15276
      e4690a38
  10. 12 Feb, 2016 1 commit
    • epriestley's avatar
      Allow task statuses to have claiming disabled · 99af097f
      epriestley authored
      Summary:
      Fixes T10343. All solutions here seem basically fine. I think adding this small bit of complexity is OK, and sorrrrt of like this behavior sometimes.
      
        - Allow disabling this behavior per-status.
        - Disable it by default for "Invalid" and "Duplicate" (I left "wontfix", since that's a resolution?).
      
      Beyond being more flexible, I think this is slightly better?
      
      Test Plan:
        - Closed a task as invalid: no claim.
        - Closed a task as resolved: claim.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10343
      
      Differential Revision: https://secure.phabricator.com/D15257
      99af097f
  11. 09 Feb, 2016 2 commits
    • epriestley's avatar
      Fix two minor points UI issues · aa6c9938
      epriestley authored
      Summary:
      Ref T4427.
      
        - When points are configured, show them on the task detail page (just a simple property, at least for now).
        - Typecast points better to avoid "joe changed points from 12 to 12." beacuse we compare the stored value (as a string) to the new value (as a double).
      
      Test Plan:
        - Saw points on detail view.
        - Created task with points, then edited it without touching points. No more spurious "changed from 12 to 12" transaction.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T4427
      
      Differential Revision: https://secure.phabricator.com/D15223
      aa6c9938
    • epriestley's avatar
      Support enabling a formal points field in Maniphest · f84130f9
      epriestley authored
      Summary:
      Ref T4427.
      
        - New config option for labels, enabling, etc., but no UI/niceness yet.
        - When enabled, add a field.
        - Allow nonnegative values, including fractional values.
        - EditEngine is nice and Conduit / actions basically just work with a tiny bit of extra support code.
      
      Test Plan:
        - Edited points via "Edit".
        - Edited points via Conduit.
        - Edited points via stacked actions.
        - Tried to set "zebra" points.
        - Tried to set -1 points.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T4427
      
      Differential Revision: https://secure.phabricator.com/D15220
      f84130f9
  12. 06 Feb, 2016 1 commit
  13. 04 Feb, 2016 1 commit
    • epriestley's avatar
      Roughly implement milestone columns on workboards · 90a04598
      epriestley authored
      Summary:
      Ref T10010. These aren't perfect but I think (?) they aren't horribly broken.
      
        - When a project is a parent project, destroy (as far as the user can tell) any custom columns.
        - When a project has milestones, automatically generate columns on the project's workboard (if it has a workboard).
        - When you move tasks between milestones, add the proper milestone tag.
        - When you move tasks out of milestones back into the backlog, add the proper parent project tag.
        - (Plenty of UI / design stuff to adjust.)
      
      Test Plan:
        - Dragged stuff between milestone columns.
        - Used a normal workboard.
        - Wasn't able to find any egregiously bad cases that did anything terrible.
      
      {F1088224}
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10010
      
      Differential Revision: https://secure.phabricator.com/D15171
      90a04598
  14. 03 Feb, 2016 1 commit
    • epriestley's avatar
      Continue lifting column layout logic out of ColumnPositionQuery · a9e98e42
      epriestley authored
      Summary:
      Ref T10010. See D15174. This gets rid of the "actually apply the change" callsite and moves it to layout engine.
      
      Next up is to make the board view use the layout engine, then throw away all the whack code in ColumnPositionQuery, then move forward with D15171.
      
      Test Plan:
        - Dragged tasks within a column.
        - Dragged tasks between columns.
        - Dragged tasks to empty columns.
        - Created a task in a column.
        - Swapped board to priority sort, dragged a bunch of stuff all over.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T10010
      
      Differential Revision: https://secure.phabricator.com/D15175
      a9e98e42
  15. 11 Jan, 2016 1 commit
  16. 22 Dec, 2015 1 commit
    • epriestley's avatar
      Improve strings for creating blocking subtasks · 57909a70
      epriestley authored
      Summary:
      Ref T6884. Ref T10004. For various reasons we previously didn't publish these transactions, but now do. This is probably a better behavior overall, but we didn't have reasonable strings for them.
      
      Parent tasks now show "alice created blocking task Txxx.".
      
      Feed now shows nothing, since "alice created task Txxx." is right next to any story we would show and showing them both seems silly.
      
      Test Plan:
        - Created subtasks.
        - Viewed parent tasks.
        - Viewed feed.
        - Saw pretty reasonable strings/stories.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T6884, T10004
      
      Differential Revision: https://secure.phabricator.com/D14849
      57909a70
  17. 09 Dec, 2015 1 commit
    • epriestley's avatar
      Replace workboard task creation with EditEngine · eef25725
      epriestley authored
      Summary: Ref T9908. This is the last of the things that need to swap over.
      
      Test Plan:
        - Created tasks from a workboard.
        - Created tasks in different columns.
        - Edited tasks.
        - Used `?parent=..`.
        - Verified that default edit form config now affects comment actions.
        - No more weird comment thing on forms, at least for now.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9908
      
      Differential Revision: https://secure.phabricator.com/D14715
      eef25725
  18. 08 Dec, 2015 1 commit
  19. 07 Dec, 2015 1 commit
    • epriestley's avatar
      Implicitly subscribe task author when they create a task · a1ccee8c
      epriestley authored
      Summary:
      Ref T9908. This is a behavioral change:
      
        - Old behavior: "Subscribers" field is default-populated with author.
        - New behavior: this transaction is just created no matter what.
      
      The new behavior is much easier to make work with form defaults, hidden fields, etc. For example, on the "Create Bug" form, I've hidden "Subscribers", but I still want the author to be subscribed.
      
      And if a user sets the default value of "Subscribers:" to "Alice, Bob", they almost certainly mean "Alice, Bob, and the task author".
      
      And I ended up deleting myself by accident way more often than I deleted myself on purpose -- especially with "Create Similar task", I'd sometimes delete all the CCs and delete myself by accident and then have to put myself back.
      
      Finally, technically speaking, restoring the old behavior is kind of hard/messy and this is much easier.
      
      Test Plan:
        - Created a task.
        - Was automatically added as a subscriber.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9908
      
      Differential Revision: https://secure.phabricator.com/D14694
      a1ccee8c
  20. 05 Dec, 2015 2 commits
    • epriestley's avatar
      Change/drop/reconcile some miscellaneous edit behaviors in Maniphest · f1744ac6
      epriestley authored
      Summary:
      Ref T9132. Open to discussion here since it's mostly product stuff, but here's my gut on this:
      
        - Change Maniphest behavior to stop assigning tasks if they're unassigned when closed. I think this behavior often doesn't make much sense. We'll probably separately track "who closed this" in T4434 eventually.
        - Only add the actor as a subscriber if they comment, like in other applications. Previously, we added them as a subscriber for other types of changes (like priority and status changes). This is more consistent, but open to retaining the old behavior or some compromise between the two.
        - Retain the "when changing owner, subscribe the old owner" behavior.
      
      Test Plan:
        - Added a comment, got CC'd.
        - Changed owners, saw old owner get CC'd.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9132
      
      Differential Revision: https://secure.phabricator.com/D14670
      f1744ac6
    • epriestley's avatar
      Rough in EditEngine for Maniphest · fa273523
      epriestley authored
      Summary:
      Ref T9132. I'm going hold this until after the release cut since it isn't going to land completely smoothly, but I think I can prep it today/tomorrow and hopefully get it close enough to working to put in HEAD on Saturday after the push.
      
      This adds the basics: new EditEngine, new EditController, and new `maniphest.edit` API endpoint.
      
      I put the new stuff at `editpro/` for now until it works a little better.
      
      Some notes on stuff this is dropping/changing/not-working-yet:
      
        - Preview for the description. I'd rather solve this by putting a "Preview" button on every Remarkup area if we want to retain it. Particularly, it does not generalize to adding custom remarkup fields in its current form. See also T3967.
        - Per-field policies are no longer enforced. They were never truly enforced anyway (for example, any user who can edit a task has always been able to edit every field via Conduit or email actions or Herald, where Herald supports things), and only really served as a hint to users. I think we can obsolete this by having installs hide/lock these fields instead. This is a desirable outcome for me, since I don't like retaining these policies and the idea of truly enforcing them properly is worrisome. These were originally added for Uber as an onboarding sort of thing. I'll prepare users for this in greater detail in the documentation.
        - Couple of minor bugs with ordering / defaults / only-one-owner-allowed in this diff that I'll clean up in future diffs before this stuff lands.
        - I don't have a concrete plan on "Create Similar Task" / "Clone" yet (do you have thoughts? Is this worth trying to do in every application?). I'll probably just mostly mimic the current behavior.
      
      Test Plan: I'll vet this more thoroughly in followups, just banged around some tasks for now and created/edited via the API.
      
      Reviewers: chad
      
      Reviewed By: chad
      
      Maniphest Tasks: T9132
      
      Differential Revision: https://secure.phabricator.com/D14659
      fa273523
  21. 23 Nov, 2015 1 commit
    • Joshua Spence's avatar
      Render Remarkup in emails · 2047483c
      Joshua Spence authored
      Summary: Ref T992. I noticed that `ManiphestTask` mail doesn't render Remarkup properly (instead, it renders Remarkup literally). I //think// this is because the code calls `addTextSection()` rather than `addRemarkupSection()`.
      
      Test Plan: Created a new Maniphest Task and saw Remarkup in the generated self-email (inspect the email contents with `./bin/mail show-outbound`). I didn't test the other affected applications.
      
      Reviewers: epriestley, #blessed_reviewers
      
      Reviewed By: epriestley, #blessed_reviewers
      
      Subscribers: Korvin
      
      Maniphest Tasks: T992
      
      Differential Revision: https://secure.phabricator.com/D14511
      2047483c
  22. 03 Aug, 2015 1 commit
  23. 08 Jun, 2015 2 commits
  24. 04 Jun, 2015 2 commits
    • epriestley's avatar
      Let Maniphest send mail again. · 0fc0af64
      epriestley authored
      Ha ha ha! Fixes T8422.
      
      Auditors: btrahan
      0fc0af64
    • epriestley's avatar
      Fix an issue with mentions in transactions · 98aae51c
      epriestley authored
      Ref T6367. Fixes T8415.
      
      Maniphest filters transactions too early. This happens automatically later. Remove the code.
      
      Transactions should be filtered per-user. If a transaction is hidden for some users, we shouldn't mail them. Move the filtering logic to be per-user.
      
      Stack:
      
      ```
      [Thu Jun 04 05:51:05.371061 2015] [:error] [pid 25111] [client 127.0.0.1:56497] [2015-06-04 05:51:05] EXCEPTION: (Exception) Transaction ("PHID-XACT-TASK-x4jlylat47s6ttr", of type "core:edge") requires a handle ("PHID-DREV-rs7jaoxbcb3av6biq4b5") that it did not load. at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:277]
      [Thu Jun 04 05:51:05.372546 2015] [:error] [pid 25111] [client 127.0.0.1:56497] arcanist(head=master, ref.master=4e83efb31d3e), instances(head=master, ref.master=db56d5d6ad91), ledger(head=master, ref.master=5694485699a4), libcore(), phabricator(head=xaction1, ref.master=04a22a8f, ref.xaction1=04a22a8f, custom=17), phutil(head=master, ref.master=c2cd90ee7aec), services(head=master, ref.master=2d76591c4f87)
      [Thu Jun 04 05:51:05.372559 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #0 <#2> PhabricatorApplicationTransaction::getHandle(string) called at [<phabricator>/src/applications/transactions/storage/PhabricatorApplicationTransaction.php:463]
      [Thu Jun 04 05:51:05.372564 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #1 <#2> PhabricatorApplicationTransaction::shouldHide() called at [<phabricator>/src/applications/maniphest/storage/ManiphestTransaction.php:163]
      [Thu Jun 04 05:51:05.372568 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #2 <#2> ManiphestTransaction::shouldHide() called at [<phutil>/src/utils/utils.php:428]
      [Thu Jun 04 05:51:05.372572 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #3 <#2> mfilter(array, string, boolean) called at [<phabricator>/src/applications/maniphest/editor/ManiphestTransactionEditor.php:380]
      [Thu Jun 04 05:51:05.372576 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #4 <#2> ManiphestTransactionEditor::shouldSendMail(ManiphestTask, array) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:957]
      [Thu Jun 04 05:51:05.372580 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #5 <#2> PhabricatorApplicationTransactionEditor::applyTransactions(ManiphestTask, array) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:2858]
      [Thu Jun 04 05:51:05.372585 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #6 <#2> PhabricatorApplicationTransactionEditor::applyInverseEdgeTransactions(DifferentialRevision, DifferentialTransaction, integer) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:569]
      [Thu Jun 04 05:51:05.372589 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #7 <#2> PhabricatorApplicationTransactionEditor::applyBuiltinExternalTransaction(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/differential/editor/DifferentialTransactionEditor.php:615]
      [Thu Jun 04 05:51:05.372594 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #8 <#2> DifferentialTransactionEditor::applyBuiltinExternalTransaction(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:489]
      [Thu Jun 04 05:51:05.372611 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #9 <#2> PhabricatorApplicationTransactionEditor::applyExternalEffects(DifferentialRevision, DifferentialTransaction) called at [<phabricator>/src/applications/transactions/editor/PhabricatorApplicationTransactionEditor.php:827]
      [Thu Jun 04 05:51:05.372616 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #10 <#2> PhabricatorApplicationTransactionEditor::applyTransactions(DifferentialRevision, array) called at [<phabricator>/src/applications/differential/controller/DifferentialCommentSaveController.php:124]
      [Thu Jun 04 05:51:05.372621 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #11 <#2> DifferentialCommentSaveController::processRequest() called at [<phabricator>/src/aphront/AphrontController.php:33]
      [Thu Jun 04 05:51:05.372625 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #12 <#2> AphrontController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:226]
      [Thu Jun 04 05:51:05.372629 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #13 phlog(Exception) called at [<phabricator>/src/aphront/configuration/AphrontDefaultApplicationConfiguration.php:226]
      [Thu Jun 04 05:51:05.372633 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #14 AphrontDefaultApplicationConfiguration::handleException(Exception) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:230]
      [Thu Jun 04 05:51:05.372637 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #15 AphrontApplicationConfiguration::processRequest(AphrontRequest, PhutilDeferredLog, AphrontPHPHTTPSink, MultimeterControl) called at [<phabricator>/src/aphront/configuration/AphrontApplicationConfiguration.php:140]
      [Thu Jun 04 05:51:05.372641 2015] [:error] [pid 25111] [client 127.0.0.1:56497]   #16 AphrontApplicationConfiguration::runHTTPRequest(AphrontPHPHTTPSink) called at [<phabricator>/webroot/index.php:19]
      ```
      
      Auditors: btrahan
      98aae51c
  25. 22 May, 2015 1 commit
  26. 22 Apr, 2015 2 commits
    • epriestley's avatar
      Possibly fix issue with subpriority recursion · f044c1e9
      epriestley authored
      Summary:
      Ref T7664. Currently, when spreading subpriorities we may recurse deeply in certain conditions. Make sure we never recurse more than one level.
      
      To try to mitigate issues with floating point precision, be more aggressive about selecting tasks to reorder.
      
      I wasn't really able to come up with a realistic test case here, and the test cases I found which sort of approximated the behavior took way too long to generate data to actually commit.
      
      This approach is inherently somewhat fragile but hopefully this is approximately good enough. We don't have a durable storage engine which can meaningfully represent double-linked lists right now.
      
      Test Plan:
        - Wrote some (slow) tests which kind of approximately hit the issue.
        - Verified they maxed out at stack depth 2 after the change.
        - Unit tests still pass.
        - Dragged some tasks around.
        - Couldn't come up with any pathological issues here by thinking about it?
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7664
      
      Differential Revision: https://secure.phabricator.com/D12511
      f044c1e9
    • epriestley's avatar
      Make adding projects a standard Herald effect · 501630d9
      epriestley authored
      Summary: Ref T7849. Lift project actions into the base class. Some day they'll be fully modular.
      
      Test Plan:
        - Wrote an "add projects" Herald rule.
        - Edited Maniphest tasks.
        - Got projects added.
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7849
      
      Differential Revision: https://secure.phabricator.com/D12503
      501630d9
  27. 13 Apr, 2015 1 commit
    • epriestley's avatar
      Modernize ManiphestTask paging and ordering · bdd1edea
      epriestley authored
      Summary:
      Ref T7803. The ApplicationSearch integration is still a little rough here, but it seems to have the correct behavior.
      
      The rest of this is now at least relatively sane, cohesive, and properly behaved.
      
      Test Plan:
        - Used all grouping and ordering queries in Maniphest. Pagingated results.
        - Used custom field ordering in Maniphest. Paginated results.
        - Paginated through the `null` section of "Assigned" and "Projects" group-by queries. Pagingation now works correctly (it does not work at HEAD).
        - Ran unit tests covering priority changes.
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7803
      
      Differential Revision: https://secure.phabricator.com/D12372
      bdd1edea
  28. 08 Apr, 2015 1 commit
    • epriestley's avatar
      Fix "To: Unknown Object" on outbound Maniphest mail with no owner · 13c0c3b8
      epriestley authored
      Summary: Fixes T7778. This was likely caused by removing an `array_filter()` somewhere in the course of T7731, but I'd rather have the code be more correct.
      
      Test Plan:
      Sent mail on a task with no owner.
      
        - Before patch: unknown recipient.
        - After patch: expected recipients.
      
      Reviewers: btrahan, joshuaspence
      
      Reviewed By: joshuaspence
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7778
      
      Differential Revision: https://secure.phabricator.com/D12320
      13c0c3b8
  29. 06 Apr, 2015 1 commit
    • epriestley's avatar
      Allow "send me an email" in personal rules to punch through settings · b16db61a
      epriestley authored
      Summary:
      Fixes T7731. When a user writes a "Send me an email" rule, always try send them an email, even if their notification settings would normally downgrade it to a notification.
      
      In particular, this is stronger than these downgrades:
      
        - Downgrades due to "self actions";
        - downgrades due to "mail tags".
      
      Test Plan:
        - Wrote various Herald rules with "Send me an email" rules.
        - Used `bin/mail list-outbound` / `show-outbound` to vet generated mail.
        - Mail reacted properly to a variety of conditions (disabled accounts, settings, "send me an email" rule, forced delivery).
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7731
      
      Differential Revision: https://secure.phabricator.com/D12300
      b16db61a
  30. 26 Mar, 2015 1 commit
    • epriestley's avatar
      Improve task subpriority movement algorithm for homogenous blocks · 73140444
      epriestley authored
      Summary:
      Fixes T7664. When there are a large number of tasks (400+) with the same subpriority (which can happen if the subpriority features are rarely used), it may take more than 30 seconds to rebalance them.
      
      Make the algorithm more aggressive about rebalancing homogenous blocks of tasks.
      
      This may need to get even fancier, but I'd guess it can process blocks 1-2 orders of magnitude larger, which should be ~all installs.
      
      (If someone still hits issues with this, I'll make it fancier.)
      
      Once a block is rebalanced, it doesn't need to be rebalanced again (at least, not as a whole block) so we basically just need to get over the initial hurdle here and then we're good.
      
      In the worst case, we can provide `bin/maniphest rebalance` or similar and do the rebalance step offline.
      
      And, in any case, we have more test coverage here now.
      
      Test Plan:
        - Existing tests.
        - New tests.
      
      Reviewers: btrahan
      
      Reviewed By: btrahan
      
      Subscribers: epriestley
      
      Maniphest Tasks: T7664
      
      Differential Revision: https://secure.phabricator.com/D12166
      73140444
  31. 21 Mar, 2015 1 commit
    • epriestley's avatar
      Fix literally thousands of drag-to-reorder priority bugs · 5aca5299
      epriestley authored
      Summary:
      Fixes T7563. Fixes T5201. Reframe this as two separate operations:
      
        - Move before or after a task.
        - Move to the beginning or end of a priority.
      
      Then:
      
        - Make all the order queries unambiguous and properly reversible, with an explicit `id` order.
        - Just reuse `ManiphestTask` to get results in the correct order.
        - Simplify the actual transaction apply logic.
        - Detect and recover from cases where tasks have identical or similar subpriorities.
      
      Test Plan:
        - Wrote and executed unit tests.
        - Dragged and dropped tasks within priorities and between priorities in the main Maniphest view.
        - Dragged and dropped tasks within priorities in the workboard view, when ordered by priority.
        - Also poked at the "natural" order, but that shouldn't be affected.
      
      Reviewers: btrahan, chad
      
      Reviewed By: chad
      
      Subscribers: chad, epriestley
      
      Maniphest Tasks: T5201, T7563
      
      Differential Revision: https://secure.phabricator.com/D12121
      5aca5299
  32. 28 Dec, 2014 1 commit
  33. 18 Dec, 2014 1 commit
    • Bob Trahan's avatar
      Maniphest - introduce needProjectPHIDs · 83db5965
      Bob Trahan authored
      Summary: Ref T5245. This is some of the associated cleanup there.
      
      Test Plan:
      foreach ManiphestTaskQuery site, I made the change (or not) and tested as follows:
      
      === Call sites where added needProjectPHIDs ===
      
      - PhabricatorHomeMainController - loaded the home page
      - ManiphestBatchEditController - batch edited some tasks (added a project)
      - ManiphestConduitAPIMethod - tested implicitly when tested ManiphestUpdateConduitAPIMethod
      - ManiphestInfoConduitAPIMethod - used the method via conduit console with input id : 1
      - ManiphestQueryConduitAPIMethod - used the method via conduit console with input ids : [1, 2]
      - ManiphestUpdateConduitAPIMethod - used the method via conduit with input id : 1 and comment : “asdasds"
      - ManiphestReportController - viewed “By User” and “By Project”
      - ManiphestSubpriorityController - changed the priority of a task via a drag on manphest home
      - ManiphestTaskMailReceiver - updated Task 1 via bin/mail receive-test with a comment that is the README
      - ManiphestTaskSearchEngine - loaded Manifest home page
      - ManiphestTaskEditController - edited a task
      - ManiphestTransactionEditor - closed a blocking task
      - ManiphestTransactionSaveController - commented on a task
      - PhabricatorProjectProfileController - viewed project with id of 1 that has a few tasks in it
      - PhabricatorSearchAttachController - merged tasks together
      - DifferentialTransactionEditor - submit a diff that references a task; commit the diff (thus closing the diff) and the task gets updated
      - PhabricatorRepositoryCommitMessageParserWorker - submit a diff that references a task; commit the diff (thus closing the diff) and the task gets updated
      
      === Calls sites where *did not* add needProjectPHIDs (they do not appear in this revision) ===
      
      - PhabricatorManiphestApplication - loaded the home page
      - ManiphestGetTaskTransactionsConduitAPIMethod - used the method via conduit console with input ids : [1, 2] ManiphestTaskDetailController - viewed a task with and without associated projects; finished workflow creating a task with a parent
      - ManiphestTransactionPreviewController - verified transaction preview showed up properly
      - PhabricatorProjectBoardViewController - viewed a board
      - PhabricatorProjectMoveController - moved a task around
      - ManiphestRemarkupRule - made a task reference like {T123}
      - ManiphestTaskQuery - executed a custom query for all tasks with page size of 2 and paginated through some tasks
      - ManiphestTaskPHIDType - nothing random seems broken? =D
      
      === Call sites where had to do something funky ===
      
      - ManiphestHovercardEventListener - loaded hover cards from task mentions
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: Korvin, epriestley
      
      Maniphest Tasks: T5245
      
      Differential Revision: https://secure.phabricator.com/D11004
      83db5965
  34. 11 Dec, 2014 2 commits
    • Bob Trahan's avatar
      Maniphest - fix bug updating tasks with blocked relationships · a2126631
      Bob Trahan authored
      Summary: Ref T5604. Found this trying to open T5604 live. Basically this internal query needs the needSubscriberPHID set to true.
      
      Test Plan: doing it live
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: Korvin, epriestley
      
      Maniphest Tasks: T5604
      
      Differential Revision: https://secure.phabricator.com/D10975
      a2126631
    • Bob Trahan's avatar
      Maniphest - use subscribers framework properly · 7d968705
      Bob Trahan authored
      Summary: Fixes T5604. This should fix some random bugs, lets us move forward more easily, and all that good stuff about killing code debt.
      
      Test Plan:
      - Conduit method maniphest.createtask
        - verified creating user subscribed
        - verified subscription transaction
      - Conduit method maniphest.update
        - verified subscribers set as specified to ccPHIDs parameter
        - verified subscription transaction
      - Herald
        - verified herald rule to add subscriber worked
        - verified no subscribers removed accidentally
      - edit controller
        - test create and verify author gets added IFF they put themselves in subscribers control box
        - test update gets set to exactly what user enters
      - lipsum generator'd tasks work
      - bulk add subscribers works
      - bulk remove subscriber works
      - detail controller
        - added myself by leaving a comment
        - added another user via explicit action
        - added another user via implicit mention
      - task merge via search attach controller
      - mail reply handler
        - add subscriber via ./bin/mail receive-test
        - unsubscribe via ./bin/mail receive-test
      
      Reviewers: epriestley
      
      Reviewed By: epriestley
      
      Subscribers: Korvin, epriestley
      
      Maniphest Tasks: T5604
      
      Differential Revision: https://secure.phabricator.com/D10965
      7d968705