Page MenuHomePhabricator

Stop cutting of Mail History for new Tasks
Closed, DuplicatePublic

Description

We are an Operations Team and use Phabricator and especially Maniphest for managing incoming Requests from our Users. If a User has a Problem, he should file a new Maniphest Task for it. They can either use the Web UI or send an Mail into Phabricator. We configured an incoming Application Mail Adress for Maniphest for that.

Sometimes Users instead write Mails to specific Members of our Team. Since we are nice guys, we wouldn't tell them to stop being lazy and create a Maniphest Task, but instead do it ourselves. However, our workflow for that isn't really handy right now. Basically it boils down to copying the relevant Parts of the Mail and copy-pasting them into the Web Interface. Of course we first tried the most obvious Solution and just forwarded Mails to our Phabricator.

The Problem with that is, that Phabricator seems to cut off the mail history for everything it receives so we basically end up with a new Ticket thats fairly empty since the interesting Part (the forwarded User Mail) got truncated. I think the rationale behind cutting of mail history is, that it doesn't make sense for replys to mails sent by Phabricator (for e.g. existing Tasks) to duplicate the entire History of the Task in every Comment received by mail.

Hoewever, since in this specific case, we will always want to create new Tasks, we can safely assume that there's no pre-existing history regarding this Task anyway and therefore everything thats forwarded is probably important. So if I send an Mail to Maniphest and it creates a new Object instead of replying to an existing one, i'd like to have the entire Mail and not just the Part i wrote myself.

(Another suggestion for our Problem (though I think much harder to implement) would be instead of cutting of Mail History to parse it instead and try to match it to existing Objects (Tasks or Comments) and use everything else that couldn't be found for Mail Body instead.)

Event Timeline

Doesn't this make Phabricator worse in every other case?

I'm going to punt this into Nuance since it's "help desk" essentially. Maybe add a comment there too.

Though I can't imagine a use case where keeping full mails for new objects makes anything worse than it is right now, I'll look into Nuance, which actually sounds nice, even though a bit overkill and far away in the stars for our use case. (and will probably bring the last of our Users who just learned to use Maniphest to finally resignate too ;-) ).

Maybe it's time to dust off the old editor and get to work a bit (though my PHP knowledge seems to be stuck at "wow, since when did PHP know something about Classes?").

Implementing my suggested behaviour might be a bit of a steep learning curve, maybe i'll just do it the lazy way and add a little if into PhabricatorMetaMTAEmailBodyParser->parseBody to don't call stripTextBody if there's some command like "!keep-fullmail" in the body (which is lazier since i can't yet grasp how to access the headers to determine what address the mail is sent to...)

If I should manage to successfully whip something up, would you be interested? If I understand the contributors code correctly this might count as the Feature Request to file my Diff against (after agreeing to your CLA of course)?

We're planning on building Nuance on the short-term roadmap (1-3 months) so use cases right now are very helpful. I'd have to leave the contribution question up to @epriestley. I don't recall other installs needing this sort of thing, so it could be a while before we look into it further.

Alright chad, from T8783 it seemed like Nuance was still far away, but 3 months doesn't sound that bad.
As suggested I commented on our use case for Nuance. I think we can probably stop annoying @epriestley with that Diff and I'll just patch it on my own installation while Nuance is still in development which is probably easier for all of us.