On this task, I got the second email, but the addressee list for the first mail was not computed correctly. This might already be resolved by changes attached to T8455, or might be a general issue related to T6367. I'll look into it.

(Test...)

I have also tried to make a NEW rule with the newly created mailing list type user but again no mail is sent. In Herald transcript i see the rule was applied ok but no mail is sent:
Conditions were met for H1 New task created·Outcome: Added mailable to mail targets.

See T5462 for discussion about publishing events into remote systems, and why Herald isn't a good choice for doing this.

Becase it's automated and i did not find the feature in Phabricator.

I presume D13184 is the fix for this, and just waiting review.

I don't think I understand. You use the email generated to go back to Phabricator to apply certain changes to the task? Why not do everything within Phabricator?

We currently have a Herald rule which send an email every time a new task is created (currently not working T8464: Herald "subscribe" rules do not take effect immediately, skipping mail about the first transaction).
The email is captured and parsed and some actions are applied to the task.
Like:

• set proper project based on some rules
• set always cc some subscribers (project leaders)
• set task view / edit policy based on project (some users forget to set the correct policy)

Please describe the problem you are having with using Phabricator.

I don't think this really matters if you've decided to fix the issue, but in case you're curious:

If you haven't run into it, T8398 has general context and guidance on this change. I've updated it to include the information here.

Worth adding: most of these were not intentionally created to refer to mailing lists. I think they used to just refer to plain email addresses, but then some migration in the past detected all of them, automatically created mailing lists for them, and automatically changed the Herald rules to refer to the mailing lists. So, I wouldn't be surprised if many installs run into similar issues.

When I run arc diff and attempt to trigger such a Herald rule:

1. arc diff succeeds, and the diff is created
2. the arc diff output includes:

Exception
[HTTP/500] Internal Server Error
{"result":null,"error_code":"ERR-CONDUIT-CORE","error_info":"Edges are not available for objects of type 'MLST'!"}

3. in the diff view (on the website), it looks as if no Herald rules were matched/triggered

I don't plan to give mailing lists their own Email Preferences panel

Thanks! :)

Yeah, I'm OK with that. Thanks!

attached revision adds the feature as a customfield to diffusion (like branches & tags). However diffusion has no diffusion.fields config yet so currently i can't disable it by default.
Additional configurability for the customfields would be nice but would in this case only allow to set the max no. of commits shown.

I want to add this kind of stuff as custom fields with options, after T6030. These aren't useful or desirable for all users, and if we add every option which someone wants we'll end up with email which isn't very useful to anyone.

• Write a subclass of HeraldAdapter. I think PhrictionDocumentHeraldAdapter is a fairly reasonable example.
• In HeraldTestConsoleController, you have to add a hacky piece of code to help Herald figure out which adapter to use.
• In your Editor, implement shouldApplyHeraldRules(), buildHeraldAdapter() and didApplyHeraldRules().
• You should now be able to use the test console to test rules.

Ah, well nevermind. haha, yeah T5602 is a slightly better solution.

This doesn't seem scalable, maintaining a blocklist, that is. Is this an actual abuse case that happened?

If we return rule as follows

Works like a charm:

This seems structurally correct but is a lot of work.

Project watchers are affected in the same way; see T6183.

The specific behavioral change this implements is that Personal (not Global or Object) Herald rules which take a "Send me an email" action can override these user settings:

Although tokenizer/typeahead stuff is churning a bit in connection with T4100 right now so this should probably wait for that to settle down.

I think we wrote this before typeaheads were modularized (T4420) so it wasn't easy to add a composite datasource at the time.

Thanks for the report and patch!