Thanks for the suggestions. We'll try to create an event listener for now. Generalizing Herald to everything would be a great improvement overall, though. If Herald is built on event listeners, then obviously there's scope for making it really customizable too.

@chengyin: that could work in some cases, but would require a huge overhead if the organization has more than a couple of developers. Add a QA department (which we don't have yet but most places do) and it becomes infeasible.

@epriestley - I was trying to add a herald rule for content source. I've hit a quasi-roadblock and wanted to check what to do. Basically PhabricatorContentSource seems to need PHIDs and plug into all that infrastructure real nice. I was thinking it should be somewhat of a hack job with a few static methods on the main class containing data. eg PhabricatorContentSource might have something like

...the alternative to getting PhabricatorContentSource on the phid infrastructure is to cut up the herald infrastructure a bit to assume not everything is a handle so readily. This was proving confusing enough though I prolly just need to take another look later.

I think we should avoid PHID'ing them, since the rules probably only care about the type (conduit, email, web), not the entire content source, and content source objects can have more fields than just the type (remote IP, sender's email address, etc).

Instead, I think we can just use a <select /> without TOO much trouble. It would look like:

[Content source] [is v] [web v]
[is not ] [email ]
[conduit ]

This can mostly be modeled on the existing "Add a flag..." action, which uses a <select /> of flag colors.

To do this, I think it looks roughly like this:

In HeraldRuleEditor._buildInput (JS), add a 'contentsource' branch, similar to the existing 'flagcolor' branch.

In HeraldRuleController->setupEditorBehavior() (PHP), add a template and default in the Javelin::initBehavior(...) call at the bottom.

Add HeraldAdapter::VALUE_CONTENT_SOURCE.

Add HeraldAdapater::CONDITION_CONTENT_SOURCE.

Map it in HeraldAdapter::getValueTypeForFieldAndCondition() (and add other mappings, like condition -> (is, is not)).

I think that does it? Slightly messy but shouldn't be too bad.

I also wonder if we should call it something other than "Content source", but don't have any ideas immediately.

This task got a little bit big, so here's what's been done via the above diffs:

can now create herald rules for maniphest tasks

actions are cc, flag, assign to user, and add project

can now make herald conditions based on content source (web, email, conduit, etc)

only deployed in maniphest

note that "web" is a bit confusing as mobile and tablet are also web technically and really are just how wide your viewport was at the time, though practically speaking you were probably on mobile / tablet

Overall, I / we could do a lot more and add tons of little features. That said, I think this covers what's been asked for so far and I think we should roll out new features as they are asked for. This is a cheap way to also not have to worry about the overall UI too much which I think can get a bit bloated pretty quickly if we just add every option ever.

Definitely appreciate feedback / ideas! Feel free to file new tasks or comment on this one.