Page MenuHomePhabricator

Allow email subjects and bodies to be more customizable
Closed, WontfixPublic

Description

It would be useful for us if we could make the subjects of emails from Differential to include a bit more information.
We work with a lot of repositories, so things like seeing the repo name and maybe branch would be helpful.

What about making the email subjects customizable with tokens?
Say, add an option like 'metamta.differential.subject-template' (could be merged with metamta.differential.subject-prefix) where you can write

${repositroy}/${branch}: D${ID}: ${title}

Is this useful for anyone else?

Event Timeline

talshiri raised the priority of this task from to Wishlist.
talshiri updated the task description. (Show Details)
talshiri added a project: Phabricator.
talshiri added a subscriber: talshiri.
talshiri updated the task description. (Show Details)
talshiri added a subscriber: epriestley.
epriestley renamed this task from Allow email subjects to be more customizable to Allow email subjects and bodies to be more customizable.Dec 9 2014, 12:41 PM
epriestley added a subscriber: Gryllida.

On body customization: we have no plans to pursue either subject or body customization at this time. If you have specific, functional issues with the current email, we may be able to adjust how mail works to resolve those problems (see T6600, for example). Basically, describe the problems the current email creates, not the desired solution (a complicated templating system).

I know a project (a big non-profit) which runs Phabricator whose users are unhappy with the emails layout and find them confusing. I imagine fixing this bug is a better solution than having them write a custom patch...

Can you provide a concrete example of how they are confusing?

In general, any move into a new workflow is going to be confusing. It's important to separate confusing because "different" and confusing because "bad". Making emails better for everyone is the correct fix.

My argument is that in some projects, phabricator is exposed to end users, and the e-mail needs to reflect that (99.9% of users don't need the reply handler actions, for example). However I don't see this argument fly in other projects where phabricator is not exposed to end users. Hence the need to make emails customizable.

You can use metamta.reply.show-hints to disable the "Reply Handler Actions" section.

We are extremely unlikely to build a templating system, and if we do it is very unlikely to happen for a year or more. If you can describe the problems you are encountering -- not your desired solution -- we may be able to address them. For example, the problem you just described is already trivially solvable with a configuration option. See:

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#describe-problems

OK. Where can I find documentation on metamta.reply.* config settings?

As an administrator, go to ConfigMail on your install to see a list of mail-related configuration options and information on what they do.

Hour user are unhappy with the emails because they can't see the related projects and have to click on the task link every time to get that information.

I also find the lack of customization for emails one of the big cons for phabricator.
I agree with Chad on the difference between "different" and "confusing", but different might be confusing for some people and yes it's just a question of getting use to this but some people might still not like them.

For me the comments in the emails without the code is useless, so I would love the comment to have the diff for that comment, I understand that for some people comments should be enough and that's ok: that's the whole point of being able to customize something.

+1 for more customizable email content. We would like to be able to see the associated projects when manifest sends an update about a task.

eadler added a project: Restricted Project.Mar 21 2016, 3:19 PM
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
eadler moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 4 2016, 9:00 PM
epriestley claimed this task.

This is a catch-all task that I don't anticipate us ever taking action on. Building some sort of templating system for mail would require a lot of resources, and using that templating system to accomplish some of the goals described in this task (like "always show associated projects") would not be significantly less complex than just forking.

So far, we've been able to address the vast majority of specific complaints about mail content by improving content. If you have changes you'd like to see to mail, file specific tasks describing problems and use cases according to Contributing Feature Requests.