Thank you very much! I've updated to HEAD and everything seems to be running smoothly now.

This should now be fixed in HEAD. Thanks for the report! Let us know if you run into anything else.

Note that this particular "reverts" (with a commit hash followed by some noise) won't be recognized after this patch: the regexp will simply fail to match. I think this is correct, although we could plausibly be more aggressive about it. But I think most cases where we'd hit this are probably silly nonsense (say, in copy/pasted output from other tools that describes the context of a change) that users would expect not to match, and that sneaky "o" characters are probably a rare case.

Thanks! This is an extremely thorough and helpful bug report.

I've heard rumors the watch team uses Phabricator.

What is the username from svn based on? My guess is there are a few things you could try:

1. Add authentication to Phabricator (such as LDAP) and link it to the account you're currently using. This assumes the account you previously committed under is tied to the LDAP account.
2. Add/update any email addresses for the account - though I'm guessing this wouldn't work since the example you gave is not an email.

This task made for a good read.

Excellent point, thanks for clarifying.

In the past, the bulk editor worked like this under a similar theory (and or laziness, I don't remember which contributed more), but we had at least one (and maybe a few? I don't recall offhand) user who failed to guess it and didn't even try the interaction in the bulk editor.

I'd be curious how important it is to the project to maintain UI consistency between Herald and Maniphest. Currently leaving the field blank in Maniphest places the task up for grabs -- wouldn't it be preferable to maintain the same expectations in Herald?

This behavior is currently expected: this construction means "no effect", not "place up for grabs".

Here's the rule transcript:

Thanks for clarifying.

That's supported after D13618.

We have a custom field for "Task type" (feature, bug, etc). Would *love* the ability to use herald with this field.

Thanks @epriestley, I'll look at that and try to modify the extension code ~

See T8957.

the above code snippet seems not working with latest phabricator version

I think (?) these are different rules, none of which have names, but this UI can clearly be improved.

I plan to just improve documentation to address this.

On a side note, does anyone know of a way to clear (PhabricatorApplicationTransactionPublishWorker) tasks from the daemon queue? These will fail forever on my system since this user does not have access. Multiple have already failed over 6000 times to send the email.

This report is about a year old, things have changed a lot, and I haven't seen other reports and can't immediately reproduce it.

Thing seem quiet now.

It works again. Thank you very much for your help!

Thanks!

I pushed this host, should be all set now?

Any workarounds you can suggest until this fix is pushed? I just tried to edit a Herald rule on this install (https://secure.phabricator.com/herald/edit/109/) and can't because of this error.

This stuff is now in HEAD, and HEAD no longer loads (or even contains) HeraldCustomAction.

I've deployed this to this server, let me know if anyone catches anything suspicious with Herald.

For the original issue: when a change is blocked, we do not send email about it. There is no way to be alerted to blocked pushes right now, and I generally don't think this is useful enough to include in the upstream. This interaction could possibly be more clear, but feels like something we just stick in the documentation to me.

This has been in the update notes for a while, but just for completeness: T8726 is changing this substantially. After those change land, you must extend HeraldAction instead of HeraldCustomAction. The API is similar, but doesn't directly map to the old class.

This should wait for T8726 since the API for actions is completely changed in unlanded work.

We don't support IE8 anymore and there would be lots to fix if so.

Yes, it's fixed.

I think Are they both clear, it's just easy to forget when filing tasks? sums it up the best: I am primarily used to other projects and other trackers. Another issue is that sometimes I'll "fast forward" my thoughts: have a problem, think through the solution, and then forget to describe the problem.