◀ Merged tasks: T2317.

Supporting Phriction would be really useful for some organizations.

We have general Phriction documents like coding guidelines, policies, etc. and ideally, updating these would notify everyone automatically.

T1514 or some similar followup will also add normal CCs to Phriction, at which point you could CC a mailing list, as a possible alternative approach.

Is there currently a way to get around this to some extent i.e. for an email to be sent to a mailing list when a new task is created?

Without being able to do so, wouldn't it basically be impossible to keep track of tasks in a team unless one refreshes the "All Tasks" list periodically or is there some other way this can be done?

You can install an event listener today, but it's a high-power / high-complexity solution:

http://www.phabricator.com/docs/phabricator/article/Events_User_Guide_Installing_Event_Listeners.html

Basically, we have good coverage on the low end (look at "All Tasks" every so often) and the high end (install an event listener) but nothing in the middle. Herald will fill that gap.

@adityar7, currently we added process in our organization for this - all the bugs simply go to one person and this person reassign to whoever should take the task. I believe this is a common practice.

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

public static function getPHIDs() {
  return array(
     self::CONTENT_SOURCE => 'PHID-CS-'.md5(self::CONTENT_SOURCE), // pretend this is the right length

...and then the PhabricatorPHIDType class would use this and other methods to generate the data it needs.

...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.

Oh, also bump the herald rule version.

@btrahan

I tried the feature today, and I was very happy about its existence! I didn't even realize it was there already.

Two more sub-features I see useful for us. I'm not sure if they would be valuable in your scope, I'd be more than happy to open individual tickets for them:

1. Instead of specifying who to notify, can it read from a member of project? The idea is to notify all the project member when a task is created into the project.
2. Can we include priorities for the condition?

Once again, thanks!

(D7436 discusses project mail; it's complicated because it runs into a lot of mailing list issues.)