Shure, I will try it again after updating my phabricator instance tomorrow morning.

Can you first verify this bug is not resolved at HEAD? https://secure.phabricator.com/book/phabcontrib/article/bug_reports/#update-phabricator

I'm mostly just curious in learning about real integration use cases.

To chime in on the hijacked direction of this thread. I had my users switch from XMPP/pidgin to conpherence for a week to see how viable it was. Here were the main complaints. My comments are added at the end of some in italics.

Personally, I'd much rather use Conpherence because I absolutely love mentions and find them very useful. Having said that, convincing 200+ others to use Conpherence is much more difficult.

(Yes, Doorkeeper is send stuff out, Nuance is pull stuff in).

What do you need from HipChat that you'd want to see in Conpherence? We've been debating the usefulness of features like Feed inside the Conpherence, curious if you'd use it and what you'd want to see.

Oh, @chad is correct, I get this mail on this install.

By default they should unless they turned self-actions off in their settings.

A related request from FreeBSD is the ability to add arbitrary email addresses to the CC.

In T8336#124234, @klimek wrote:

In T8336#116857, @epriestley wrote:

we want to decide which emails just do not get sent, because a list will be cc'ed

T5791 will let you write global Herald rules for outbound mail, like:

When [all] of these conditions match:
[Sending application][is][Differential]
[Recipients][include any of][mailing list a, mailing list b]
[Transactions][do not include][create, update, comment, accept, reject]

Take these actions:
[Do not deliver this message to][mailing list a, mailing list b]

If you don't need this level of power and the existing Settings → Email Preferences controls are sufficient, you could possibly put the mailing list email address on a user account, then log in with that user and set their preferences.

I don't plan to give mailing lists their own Email Preferences panel, nor to implement any set of controls with a level of power between "Email Preferences" and "Herald".

---

we need to be able to basically replace everything that goes into an email

At HEAD, most of the default mail behavior is defined by custom fields, which can be disabled and reordered. Disabling a custom field removes that section of the mail. Specifically, you can edit differential.fields in Config to review, reorder, and disable fields.

These sections are currently not driven by custom fields: the actual transaction messages, INLINE COMMENTS, CHANGED PRIOR TO COMMIT, REVISION DETAIL, AFFECTED FILES, CHANGE DETAILS.

I'm currently playing around with this (as integrating broke our minimal email mode in a non-trivial way). We're getting very close to being able to get rid of most of our customizations - there are currently 2 things that I can't switch off (or I'm missing something):

• the actions at the top of the mail (never want to see those)
• the email prefs at the bottom (for people on the mailing list who don't have a phab account those are unnecessary)

In T8336#116857, @epriestley wrote:

we want to decide which emails just do not get sent, because a list will be cc'ed

T5791 will let you write global Herald rules for outbound mail, like:

When [all] of these conditions match:
[Sending application][is][Differential]
[Recipients][include any of][mailing list a, mailing list b]
[Transactions][do not include][create, update, comment, accept, reject]

Take these actions:
[Do not deliver this message to][mailing list a, mailing list b]

If you don't need this level of power and the existing Settings → Email Preferences controls are sufficient, you could possibly put the mailing list email address on a user account, then log in with that user and set their preferences.

I don't plan to give mailing lists their own Email Preferences panel, nor to implement any set of controls with a level of power between "Email Preferences" and "Herald".

---

we need to be able to basically replace everything that goes into an email

At HEAD, most of the default mail behavior is defined by custom fields, which can be disabled and reordered. Disabling a custom field removes that section of the mail. Specifically, you can edit differential.fields in Config to review, reorder, and disable fields.

These sections are currently not driven by custom fields: the actual transaction messages, INLINE COMMENTS, CHANGED PRIOR TO COMMIT, REVISION DETAIL, AFFECTED FILES, CHANGE DETAILS.

I'm interested in implementing this feature, is this something that would be accepted to be merged in upstream?

Also, Herald is intentionally stronger than self-actions.

T8682 describes another recipe, if [body][does not contain]['magic word'], [block commit] to let you create warnings/prompts when committing.

This is a very niche use case. It also tends to conflate the pusher (who we may not know, for imported repositories), the committer, and the author. This makes me hesitant about implementing it.

Yeah, they're functionally identical.

I think this relates to T8644, which relates to the discussion starting T7804#107408.

One thing I was thinking: having the ability to ignore commits in Herald based on tag would solve this, you could just set Herald to ignore any tag matching phabricator/diff/\d+

See also some discussion in T7804.

I really enjoyed reading this comment thread! :)

This action should read "Add Subscribers".

Thanks! I think D13245 should really fix this.

I changed the Herald task to add the tasknotify user as subscriber. Now i get the mail.
Still the bug if the Herald action is to send mail.

One thing i notice is that your Herald rule just adds a subscriber. In my case it's set to send a mail to the tasknotification user.

So it seems that not all recipients are loaded when creating the outbound mail.

I found the mail in list-outbound with status Void:

I can't reproduce this. I created T8499 and immediately received mail about it to my "molepeople" list:

Any updates ? Is the bug confirmed ?

Presuming resolved, yell if anyone's still running into issues.

I have one Herald rule:

Do you mind giving complete steps to reproduce here, I want to make sure we’re all on the same page as to your specific bug. Perhaps we fixed something else.

That is the process we always do.
Still not working.

You also need to stop the deamons, restart php/apache, and start them back up.

git pull from github repo

How did you update?

I did an update this morning and we have the same behaviour. No mail is sent on task newly created.

It's only issuing one statement so it will jump from 0% to 100% after adding the key, but it might take a bit if you have a lot of data in the table.

We saw a bunch of lines like:

Updated mailing lists in Herald action 1466.

I believe the error is now fixed at HEAD.

Thanks for tracking down the root cause! It'd be great if the fix were landed today so that we could pull in this fix when also pulling in the fix for T8455.