1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-11 09:22:40 +01:00
Commit graph

66 commits

Author SHA1 Message Date
Bob Trahan
660f1f3e64 Add herald support for Maniphest
Summary:
standing on the shoulders of the badass work to move Maniphest to ApplicationTransactions, this diff implements a few methods and adds an adapter class.

For now, we can add cc and flag tasks. I figure see what people ask for?  Ref T1368.

Test Plan: created herald rules for title and description text hits. made tasks and verified CC and flags worked.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, aran

Maniphest Tasks: T1368, T1638

Differential Revision: https://secure.phabricator.com/D7122
2013-09-25 11:50:15 -07:00
epriestley
26a226b51a Remove a bunch of reundant checks for transactions with no effect from Maniphest
Summary: Ref T2217. These checks are no longer necessary, ApplicationTransactions handle them for us.

Test Plan:
  - Made a no-effect edit, verified no new transactions showed up.
  - Made real edits, saw them happen and leave transactions.
  - Made an edit which just reorders CCs, saw it detected as no-effect.
  - As above, with projects.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7117
2013-09-25 11:18:38 -07:00
epriestley
6d45a2e09b Restore some missing features from Maniphest mail
Summary:
Ref T2217. Fixes two issues:

  # The "task created" email didn't include the task description, but should.
  # We were treaging the "status" event as the "create", but that's kind of a mess. Treat the "title" event as the "create" instead. This makes initial emails say "[Created]".

Test Plan: Created some tasks, got better emails.

Reviewers: btrahan, chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7115
2013-09-25 11:16:55 -07:00
epriestley
01ecf1a236 Rename ManiphestTransactionPro -> ManiphestTransaction
Summary: Ref T2217. Pro is the new standard.

Test Plan: Lots of `grep`, made a pile of Maniphest views/edits.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7093
2013-09-24 10:49:06 -07:00
epriestley
2f694f5e3f Gut ManiphestTransactionEditor
Summary:
Ref T2217. Removes most of the code from ManiphestTransactionEditor.

  - Provides mail tag support in ManiphestTransactionEditorPro.
  - There was one more write (subscribe/unsubscribe button) that I'd missed; modernize that.

Test Plan:
  - Clicked subscribe/unsubscribe.
  - Made some edits, verified mail had appropriate mail tags.

Reviewers: btrahan, garoevans

Reviewed By: garoevans

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7091
2013-09-24 06:27:07 -07:00
epriestley
bf14bb45f1 Route Maniphest comments/detail edits through new code
Summary: Ref T2217. When you add comments (or use that interface to make updates), ship it through the new code.

Test Plan: Added comments, made other changes to Maniphest tasks.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7088
2013-09-23 14:33:09 -07:00
epriestley
889eac44ae Route attached objects through new editor
Summary: Ref T2217. Nothing too surprising here. This transaction type is weird and should be replaced with the mainstream EDGE type at some point after things clear up more.

Test Plan: Attached and detached revisions and mocks.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7085
2013-09-23 14:32:41 -07:00
epriestley
6fd1e01fe7 Run Maniphest batch edits through modern editor
Summary:
Ref T2217. Swaps batch edits to modern editor.

Also, fix some issues with required fields and viewers being required to render certain standard fields (notably, date).

Test Plan: Made various batch edits, verified they went through properly.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7083
2013-09-23 14:32:22 -07:00
epriestley
2bc46f097e Run Maniphest Conduit writes through new editor
Summary: Ref T2217. Swap the editors for the Conduit writes.

Test Plan: Made a bazillion Conduit calls, saw tasks updated appropriately.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7082
2013-09-23 14:32:08 -07:00
epriestley
69523d30cc Add new-style transaction editor to Maniphest and switch priority edits to it
Summary: Ref T2217. All the reads route through new code already, start swapping writes over. This is the simplest writer, used when the user drag-and-drops stuff on the task list.

Test Plan: Dragged and dropped stuff across priorities. Got a transaction and some email. Verified the email and transaction looked OK, threaded properly, etc.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7080
2013-09-23 14:31:47 -07:00
epriestley
d9aa9eec78 Route Maniphest email through the transaction core
Summary: Ref T2217. Build transaction details using transaction code.

Test Plan: See screenshot.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7074
2013-09-23 14:30:20 -07:00
epriestley
7abe9dc4c0 Migrate all Maniphest transaction data to new storage
Summary:
Ref T2217. This is the risky, hard part; everything after this should be smooth sailing. This is //mostly// clean, except:

  - The old format would opportunistically combine a comment with some other transaction type if it could. We no longer do that, so:
    - When migrating, "edit" + "comment" transactions need to be split in two.
    - When editing now, we should no longer combine these transaction types.
    - These changes are pretty straightforward and low-impact.
  - This migration promotes "auxiliary field" data to the new CustomField/StandardField format, so that's not a straight migration either. The formats are very similar, though.

Broadly, this takes the same attack that the auth migration did: proxy all the code through to the new storage. `ManiphestTransaction` is now just an API on top of `ManiphestTransactionPro`, which is the new storage format. The two formats are very similar, so this was mostly a straight copy from one table to the other.

Test Plan:
  - Without performing the migration, made a bunch of edits and comments on tasks and verified the new code works correctly.
  - Droped the test data and performed the migration.
  - Looked at the resulting data for obvious discrepancies.
  - Looked at a bunch of tasks and their transaction history.
  - Used Conduit to pull transaction data.
  - Edited task description and clicked "View Details" on transaction.
  - Used batch editor.
  - Made a bunch more edits.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7068
2013-09-23 14:25:28 -07:00
epriestley
17e1732152 Route all ManiphestTransaction reads through a single class
Summary:
Ref T2217. I'm going to do the fake-double-writes ("double reads"?) thing where we proxy the storage that worked pretty well for auth. That is:

  - (Some more cleanup diffs next, maybe?)
  - Move all the data to the new storage, and make `ManiphestTransaction` read and write by wrapping `ManiphestTransactionPro`.
  - If nothing breaks, it's a straight shot to nuking ManiphestTransaction callsite by callsite.

I think Maniphest is way easier than Differential, because there are very few query sites and no inline comments.

Test Plan: `grep` to find callsites. Loaded task view, called Conduit.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T2217

Differential Revision: https://secure.phabricator.com/D7067
2013-09-23 14:25:14 -07:00
epriestley
01eedd6e6a Make ManiphestCustomField actually implement the interface it ostensibly exposes
Summary: There's a bunch of stuff that lives only in AuxiliaryField which is called on objects which may be ManiphestCustomFields right now. This is basically a list of remaining API methods which need to be moved to the new stuff. This enables construction of new-style custom fields.

Test Plan: Created a sophisticated Maniphest custom field.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7013
2013-09-16 16:05:29 -07:00
epriestley
dd4537edef Route Maniphest editing and transactions primarily through shared code
Summary: Ref T418. Although Maniphest does not use ApplicationTransactions, we can fake a lot of it and provide a more uniform API. Deletes as much custom code from Maniphest as possible along the edit workflows, using core code instead.

Test Plan:
With custom fields:

  - Edited a task.
  - Created a task.
  - Queried a task with Maniphest.
  - Updated a task with Maniphest.
  - Used `?template=nnn` to create a similar task.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T418

Differential Revision: https://secure.phabricator.com/D7001
2013-09-16 16:03:01 -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
67da5d6e4b Add Subscribe option to maniphest
Summary:
Same as //Subscribe//, //Unsubscribe// and //Automatically Subscribed// in differential.

Manually updated library map as windows is fun!

Test Plan: Subscribe, Unsubscribe!

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D5809
2013-05-03 15:47:39 -07:00
epriestley
0a069cb55a Require a viewer to load handles
Summary:
Unmuck almost all of the we-sort-of-have-viewers-some-of-the-time mess.

There are a few notable cases here:

  - I used Omnipotent users when indexing objects for search. I think this is correct; we do policy filtering when showing results.
  - I cheated in a bad way in the Remarkup object rule, but fixing this requires fixing all the PhabricatorRemarkupEngine callsites (there are 85). I'll do that in the next diff.
  - I cheated in a few random places, like when sending mail about package edits. These aren't a big deal.

Test Plan:
  - Grepped for all PhabricatorObjectHandleData references.
  - Gave them viewers.

Reviewers: vrana

Reviewed By: vrana

CC: aran, edward

Maniphest Tasks: T603

Differential Revision: https://secure.phabricator.com/D5151
2013-02-28 17:15:09 -08:00
epriestley
69dcd47751 Fix two cases where we load Commit handles without a viewer
I missed these in testing D5139 because they aren't in the web UIs and I am dumb and can not brain today.

Auditors: vrana
2013-02-27 11:44:52 -08:00
epriestley
f6b1964740 Improve Search architecture
Summary:
The search indexing API has several problems right now:

  - Always runs in-process.
    - It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
    - Being able to use the task queue will also make rebuilding indexes faster.
    - Instead, make the API phid-oriented.
  - No uniform indexing API.
    - Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
    - Instead, provide a uniform API.
  - No uniform CLI.
    - We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
    - Instead, let indexers expose documents for indexing.
  - Not application-oriented.
    - All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
    - Instead, move indexers to applications and load them with SymbolLoader.

Test Plan:
  - `bin/search index`
    - Indexed one revision, one task.
    - Indexed `--type TASK`, `--type DREV`, etc., for all types.
    - Indexed `--all`.
  - Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
    - Creating users is a pain; searched for a user after indexing.
    - Creating commits is a pain; searched for a commit after indexing.
    - Mocks aren't currently loadable in the result view, so their indexing is moot.

Reviewers: btrahan, vrana

Reviewed By: btrahan

CC: 20after4, aran

Maniphest Tasks: T1991, T2104

Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 14:21:31 -08:00
epriestley
3ceaad1aa8 Add basic email support to Pholio
Summary: These emails aren't yet useful, but thread/multiplex/etc correctly.

Test Plan: Got some Pholio emails.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T2097

Differential Revision: https://secure.phabricator.com/D3842
2012-11-21 17:39:46 -08:00
vrana
ef85f49adc Delete license headers from files
Summary:
This commit doesn't change license of any file. It just makes the license implicit (inherited from LICENSE file in the root directory).

We are removing the headers for these reasons:

- It wastes space in editors, less code is visible in editor upon opening a file.
- It brings noise to diff of the first change of any file every year.
- It confuses Git file copy detection when creating small files.
- We don't have an explicit license header in other files (JS, CSS, images, documentation).
- Using license header in every file is not obligatory: http://www.apache.org/dev/apply-license.html#new.

This change is approved by Alma Chao (Lead Open Source and IP Counsel at Facebook).

Test Plan: Verified that the license survived only in LICENSE file and that it didn't modify externals.

Reviewers: epriestley, davidrecordon

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T2035

Differential Revision: https://secure.phabricator.com/D3886
2012-11-05 11:16:51 -08:00
20after4
d7f6bd42d6 Use getProductionURI instead of getURI for emails.
Summary: 'TASK DETAIL' links point to the non-production uri.  Our daemons run in an environment that uses different baseUrl because we can't use https locally (https is provided by our load balancers)

Test Plan: check emails generated with a non-production environment. See that the TASK DETAIL link points to production url.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D3877
2012-11-02 13:43:38 -07:00
Bob Trahan
ae616e82d3 add a few more email preferences for differential and maniphest
Summary: this makes notifications work better for folks who choose to handle things in Phabricator and not over email

Test Plan: had my test account and "real" account battle each other on a few tasks and divs. Noted that I received emails appropos to the respective settings.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T1977

Differential Revision: https://secure.phabricator.com/D3856
2012-10-31 17:11:04 -07:00
epriestley
6b39af4022 Mark Maniphest notifications read if we send the user an email
Summary:
See D3784, T1403. When we send a user an email and a notification from Maniphest, mark the notification as read.

(It would be nice to do the thing with `multiplexMail()` a little less hackily, but it gets very complicated to do correctly because we require handles but sometimes do not have an actor/user so I'm punting for now.)

Test Plan: Acted on a task, verified notification was marked read because I received an email.

Reviewers: vrana, btrahan

Reviewed By: vrana

CC: aran

Maniphest Tasks: T1403

Differential Revision: https://secure.phabricator.com/D3789
2012-10-23 12:02:40 -07:00
Bob Trahan
d9c6e07f2c If users are on the email to Phabricator, do not send them the Phabricator reply.
Summary: When we receive an email, figure out if any of the other tos and ccs are users. If they are, pass their phids through the stach as "exclude phids" and exclude them from getting the email.

Test Plan: used the various applications (audit, differential, maniphest) and noted emails were sent as expected.

Reviewers: epriestley, vrana

Reviewed By: vrana

CC: aran, Korvin, vrana

Maniphest Tasks: T1676

Differential Revision: https://secure.phabricator.com/D3645
2012-10-10 10:18:23 -07:00
epriestley
378feb3ffb Centralize rendering of application mail bodies
Summary: This is a minor quality-of-life improvement to prevent D2968 from being as nasty as it is.

Test Plan: Ran unit tests; generated Differential, Maniphest and Diffusion emails and verified the bodies looked sensible.

Reviewers: btrahan, vrana

Reviewed By: vrana

CC: aran

Maniphest Tasks: T931

Differential Revision: https://secure.phabricator.com/D2986
2012-07-16 19:01:43 -07:00
epriestley
9f4cfd40bc Insert Maniphest transactions when edges are edited
Summary:
  - See D2741.
  - When EdgeEditor performs edits, emit events.
  - Listen for Maniphest edge events and save the changes as transactions.
  - Do all this in a reasonably generic way that won't take too much rewriting as we use edges more generally.

Test Plan: Attached and detached commits from tasks, saw reasonable-looking transactions spring into existence.

Reviewers: btrahan, davidreuss

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D2906
2012-07-02 15:42:06 -07:00
vrana
892a2d1b61 Make Thread-Topic human readable
Summary:
Some e-mail clients display this header and it needs to be constant.

This is somehow involved but I doubt that there is a simpler solution.

Test Plan:
Applied SQL patch.
Commented on revision, commented on commit, changed package.
Verified that the `Thread-Topic` has constant and human readable value.

Reviewers: epriestley

Reviewed By: epriestley

CC: ola, aran, Korvin

Differential Revision: https://secure.phabricator.com/D2745
2012-06-14 11:36:34 -07:00
vrana
80de8c93c9 Stabilize Thread-Topic
Summary: NOTE: This can break current ongoing conversations.

Test Plan: Commented on a revision and checked the header in the e-mail.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, Korvin

Maniphest Tasks: T1340

Differential Revision: https://secure.phabricator.com/D2723
2012-06-12 10:58:41 -07:00
vrana
2793828795 Refactor setting e-mail subjects
Summary:
It seems that Outlook and Mail.app mostly ignores the threading headers and thread primarily by subject.
They are also very picky about the Re: part in the header.
I guess that's because users of these clients often hit Reply when they want to create a new message to the sender of an e-mail.

We need both of these applications to work with the same setting because we don't use multiplexing to prevent sending multiple e-mails to people in lists.
I also believe that the default behavior should just work in most setups.

I've tried several different combinations of putting "Re:" and none of them seems to always work in both clients.

This diff at least adds more abstraction to the code which should prevent copy/paste errors (two fixed by this diff!).

Test Plan: Sent several e-mails with varying subject, verified that they look as before in Outlook and Mail.app.

Reviewers: epriestley, nh

Reviewed By: epriestley

CC: aran, Korvin

Differential Revision: https://secure.phabricator.com/D2709
2012-06-11 19:07:21 -07:00
Keebuhm Park
284d7b6a46 Minor fixes to maniphest feed/notification
Summary:
Added `renderNotificationView()` abstract function to `PhabricatorFeedStory` base class.
Fixed duplicate line in `PhabricatorFeedStoryManiphest` class.
Fixed spacing/formatting in `ManiphestTransactionEditor`.

Test Plan: No functional changes

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: allenjohnashton, ddfisher, aran, Korvin

Differential Revision: https://secure.phabricator.com/D2698
2012-06-08 19:11:53 -07:00
John-Ashton Allen
ec37ce3db7 Add more detailed story actions for maniphest.
Summary:
TransactionType gives us more information than
update, open, close, assign.  We can display those in feed/notifications along with and comments on the actions.

Test Plan: did on local machine tested out.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: ddfisher, keebuhm, aran, Korvin

Differential Revision: https://secure.phabricator.com/D2683
2012-06-08 11:28:49 -07:00
John-Ashton Allen
3a6ee79190 Adds base notification application
Summary: First diff in a series of diffs to add notifications to Phabricator. This is the notification application ONLY. This commit does not include the changes to other applications that makes them add notifications. As such, no notifications will be generated beyond the initial database import.

Test Plan: This is part of the notifications architecture which has been running on http://theoryphabricator.com for the past several months.

Reviewers: epriestley, btrahan, ddfisher

Reviewed By: epriestley

CC: allenjohnashton, keebuhm, aran, Korvin, jungejason, nh

Maniphest Tasks: T974

Differential Revision: https://secure.phabricator.com/D2571
2012-06-08 06:32:02 -07:00
vrana
6cc196a2e5 Move files in Phabricator one level up
Summary:
- `kill_init.php` said "Moving 1000 files" - I hope that this is not some limit in `FileFinder`.
- [src/infrastructure/celerity] `git mv utils.php map.php; git mv api/utils.php api.php`
- Comment `phutil_libraries` in `.arcconfig` and run `arc liberate`.

NOTE: `arc diff` timed out so I'm pushing it without review.

Test Plan:
/D1234
Browsed around, especially in `applications/repository/worker/commitchangeparser` and `applications/` in general.

Auditors: epriestley

Maniphest Tasks: T1103
2012-06-01 12:32:44 -07:00
epriestley
09c8af4de0 Upgrade phabricator to libphutil v2
Summary: Mechanical changes from D2588. No "Class.php" moves yet.

Test Plan: See D2588.

Reviewers: vrana, btrahan, jungejason

Reviewed By: vrana

CC: aran

Maniphest Tasks: T1103

Differential Revision: https://secure.phabricator.com/D2591
2012-05-30 14:26:29 -07:00
epriestley
c458768415 Fix various threading issues, particularly in Gmail
Summary:
  - Add an explicit multiplexing option, and enable it by default. This is necessary for Mail.app to coexist with other clients ("Re:" breaks outlook at the very least, and generally sucks in the common case), and allows users with flexible clients to enable subject variance.
  - Add an option for subject line variance. Default to not varying the subject, so mail no longer says [Committed], [Closed], etc. This is so the defaults thread correctly in Gmail (not entirely sure this actually works).
  - Add a preference to enable subject line variance.
  - Unless all mail is multiplexed, don't enable or respect the "Re" or "vary subject" preferences. These are currently shown and respected in non-multiplex cases, which creates inconsistent results.

NOTE: @jungejason @nh @vrana This changes the default behavior (from non-multiplexing to multiplexing), and might break Facebook's integration. You should be able to keep the same behavior by setting the options appropriately, although if you can get the new defaults working they're probably better.

Test Plan:
Send mail from Maniphest, Differential and Audit. Updated preferences. Enabled/disabled multiplexing. Things seem OK?

NOTE: I haven't actually been able to repro the Gmail threading issue so I'm not totally sure what's going on there, maybe it started respecting "Re:" (or always has), but @cpiro and @20after4 both reported it independently. This fixes a bunch of bugs in any case and gives us more conservative set of defaults.

I'll see if I can buff out the Gmail story a bit but every client is basically a giant black box of mystery. :/

Reviewers: btrahan, vrana, jungejason, nh

Reviewed By: btrahan

CC: cpiro, 20after4, aran

Maniphest Tasks: T1097, T847

Differential Revision: https://secure.phabricator.com/D2206
2012-04-12 09:31:03 -07:00
vrana
8813c7be0e Use assert_instances_of() everywhere but Differential and Diffusion
Summary: NOTE: This is not produced by a script so there might be errors. Please review carefully.

Test Plan: Browse around.

Reviewers: epriestley

Reviewed By: epriestley

CC: aran

Differential Revision: https://secure.phabricator.com/D2091
2012-04-03 14:53:20 -07:00
epriestley
e7853e4801 Allow tasks to be subprioritized by drag-and-drop
Summary:
Like the title says, similar to Facebook Tasks.

Not sure how I really feel about this, but I guess it's kind of OK? I never used
this feature in Facebook Tasks but I think some people like it.

The drag-and-drop to repri across priorities feels okayish.

Because subpriority is a double and we just split the difference when
reprioritizing, you lose ~a bit of precision every time you repri two tasks
against each other and so you can break it by swapping the priorities of two
tasks ~50 times. This case is pretty silly and pathological. We can add some
code to deal with this at some point if necessary.

I think this also fixes the whacky task layout widths once and for all.

(There are a couple of minor UI glitches like headers not vanishing and header
counts not updating that I'm not fixing because I am lazy.)

Test Plan: Dragged and dropped tasks around.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, epriestley, mgummelt

Maniphest Tasks: T859

Differential Revision: https://secure.phabricator.com/D1731
2012-04-02 12:12:04 -07:00
vrana
4fba549a99 Use PhabricatorEnv::newObjectFromConfig() wherever possible
Test Plan:
/mail/send/
scripts/aphront/aphrontpath.php /

Reviewers: epriestley

Reviewed By: epriestley

CC: aran, epriestley

Differential Revision: https://secure.phabricator.com/D1983
2012-03-21 14:57:52 -07:00
epriestley
d0af617818 Add "final" to (almost) everything else
Summary: Last of the big final patches. Left a few debatable classes (12 out of about 400) that I'll deal with individually eventually.

Test Plan: Ran testEverythingImplemented.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, epriestley

Maniphest Tasks: T795

Differential Revision: https://secure.phabricator.com/D1881
2012-03-13 16:21:04 -07:00
epriestley
df361a0761 Improve rendering for Maniphest custom fields
Summary: We render these in a realtively unreadable way right now; allow customization and provide reasonable defaults.

Test Plan: Looked at some tasks with custom fields on them.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, epriestley

Maniphest Tasks: T930

Differential Revision: https://secure.phabricator.com/D1790
2012-03-06 15:10:17 -08:00
epriestley
bfea830d09 Add email preferences to receive fewer less-important notifications
Summary:
A few similar requests have come in across several tools and use cases that I
think this does a reasonable job of resolving.

We currently send one email for each update an object receives, but these aren't
always appreciated:

  - Asana does post-commit review via Differential, so the "committed" mails are
useless.
  - Quora wants to make project category edits to bugs without spamming people
attached to them.
  - Some users in general are very sensitive to email volumes, and this gives us
a good way to reduce the volumes without incurring the complexity of
delayed-send-batching.

The technical mechanism is basically:

  - Mail may optionally have "mail tags", which indicate content in the mail
(e.g., "maniphest-priority, maniphest-cc, maniphest-comment" for a mail which
contains a priority change, a CC change, and a comment).
  - If a mail has tags, remove any recipients who have opted out of all the
tags.
  - Some tags can't be opted out of via the UI, so this ensures that important
email is still delivered (e.g., cc + assign + comment is always delivered
because you can't opt out of "assign" or "comment").

Test Plan:
  - Disabled all mail tags in the web UI.
  - Used test console to send myself mail with an opt-outable tag, it was
immediately dropped.
  - Used test console to send myself mail with an opt-outable tag and a custom
tag, it was delivered.
  - Made Differential updates affecting CCs with and without comments, got
appropriate delivery.
  - Made Maniphest updates affecting project, priority and CCs with and without
comments, got appropriate delivery.
  - Verified mail headers in all cases.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, epriestley, moskov

Maniphest Tasks: T616, T855

Differential Revision: https://secure.phabricator.com/D1635
2012-02-17 22:57:07 -08:00
epriestley
1a1da7d6c2 Integrate auxiliary fields into Maniphest transactions
Summary:
  - When changing auxiliary field values, use transactions.
  - Clean up some of the load/save logic for auxiliary fields so it's a little
more performant.

NOTE: The transaction display of auxiliary fields is incredibly hacky, I'll
follow up with a more nuanced approach but wanted to limit scope here.

Test Plan: Created and edited tasks with custom fields configured; created and
edited tasks without custom fields configured.

Reviewers: btrahan, jungejason, zeeg

Reviewed By: jungejason

CC: aran, jungejason

Maniphest Tasks: T418

Differential Revision: https://secure.phabricator.com/D1283
2011-12-27 16:01:49 -08:00
epriestley
ee620bde6d Publish feed stories from Maniphest
Summary: I didn't get around to this earlier; add Feed/Maniphest integration.
This is partly motivated by wanting Projects to not be terrible. Pretty
straightforward.

Test Plan:
  - Created, updated, reassigned and closed a task.
  - Verified feed stories render reasonably.

Reviewers: btrahan, jungejason

Reviewed By: btrahan

CC: aran, btrahan

Maniphest Tasks: T681

Differential Revision: 1232
2011-12-20 09:55:29 -08:00
epriestley
4156cf6bd9 Add an optional configuration option to set 'Precedence: bulk' headers on
transactional mail

Summary: See T571. SES refuses to deliver mail with this header and there are
various reports of other issues on the internet so I'm defaulting it to off.

Test Plan: Set config to true, tried to send mail, SES rejected it because of
"Precedence: bulk" header.

Reviewers: bmaurer, ola, jungejason, nh, aran

Reviewed By: aran

CC: aran, epriestley, bmaurer

Differential Revision: 1032
2011-10-23 14:25:13 -07:00
epriestley
4452239d61 Make maniphest add CCs when users are @mentioned
Summary:
We don't currently add CCs, but should (similar to how Differential works).

This also fixes some problems where you can get no-op CC transactions, and makes
mentions a little less aggressively colored.

Test Plan: Applied a bunch of CC/mention transactions to tasks and observed the
behavior.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran, codeblock
CC: aran, jungejason
Differential Revision: 634
2011-07-09 16:54:59 -07:00
epriestley
78c695bad2 Slightly improve Maniphest documentation. 2011-07-04 13:04:22 -07:00
epriestley
4469ef8f30 Allow Maniphest to scale to a massive size
Summary:
Maniphest is missing some keys and some query strategy which will make it
cumbersome to manage more than a few tens of thousands of tasks.

Test Plan:
Handily manipulated 100k-scale task groups. Maniphest takes about 250ms to
select and render pages of 1,000 tasks and has no problem paging and filtering
them, etc. We should be good to scale to multiple millions of tasks with these
changes.

Reviewed By: gc3
Reviewers: fratrik, jungejason, aran, tuomaspelkonen, gc3
Commenters: jungejason
CC: anjali, aran, epriestley, gc3, jungejason
Differential Revision: 534
2011-06-28 06:41:05 -07:00
epriestley
d6bfdf6ce7 Carry "Message-ID" across email replies to prevent Gmail conversation splitting
Summary:
See T251. In Gmail, conversations split if you reply to them and the next email
does not "In-Reply-To" your message ID. When an action is triggered by an email,
carry its Message-ID through the stack and use it for "In-Reply-To" and
"References" on the subsequent message.

Test Plan:
Live-patched phabricator.com and replied to a Maniphest thread in Gmail without
disrupting the thread. Locally replied to Maniphest and Differential threads and
verified Message-ID was carried across the reply boundary.

Reviewed By: rm
Reviewers: tcook, jungejason, aran, tuomaspelkonen, rm
CC: aran, epriestley, rm
Differential Revision: 498
2011-06-22 14:59:40 -07:00