Please describe the root problem when requesting a feature. See Contributing Feature Requests. If you aren't sure what we mean, see Describing Root Problems for some more details.

No problem, thanks for the detailed request. Let me know if I missed anything or you run into trouble.

Awesome. Thank you!

Oh, the weird/nonstandard stuff in my regexp, if you or some future reader hasn't seen it before:

After D15254, you should be able to use either "does not contain" or "does not match regexp" against text or list-of-text fields, including "Affected files".

(I think we're happy with the feature-space here)

We ran into a case where archived packages were trigger builds, which didn't feel right and was causing problkems. I'm not sure what the default behavior loadAffectedPackages should be or what would be most consistent with how archiving is handled elsewhere.

(This is definitely confusing, but I'm not sure what the best way forward is offhand. I'm hesitant to just make Herald always trigger without putting more thought into the issue.)

Thanks, @epriestley (and sorry for getting back to you so late)! You're totally right that this is because I didn't actually update the revision.

Herald has some very unusual code to preserve control values when you swap the selectors. Generally, the issue is:

Yeah, these are "common" controls, but I think they only get used in Herald?

oops~

Sounds good.

Ok, as far as I'm concerned I'm happy with what P1895 provides and this task can be closed. The more elegant solution seems to be part of T9530, making this task entirely superfluous.

See also T9853, which includes an extension to do this.

I'll have a look at T9853 (sorry, didn't find that, when I searched... might have had "open" set), it looks close to what I had in mind at a first glance.

See also T9853, which includes an extension to do this.

I'm hitting the same problem using Chrome (Version 41.0.2272.89 (64-bit)).
However when using firefox, I do not have this problem so it seems to be browser related.

👍

Yeah, completeness is definitely sufficient motivation if you're up for it.

I've also noticed that Herald Transactions have PHID, but not PHIDType class (https://secure.phabricator.com/diffusion/P/browse/master/src/applications/herald/storage/transcript/HeraldTranscript.php;3f439e25bc586ff8bae203a47625f6c360e4402a$193). Wasn't sure if "completeness" is a good enough reason to make the changes (PHIDType + teach the Query object about withPHIDs, and maybe a bit more).

I think I'll have time for this this week/weekend.

I upgraded a 6 month old installation to HEAD. Can it be related? Didn't experience any other issues.

What I created to test:

I can't reproduce this at HEAD. Are there more complete instructions we can follow?

I removed this because the implementation was pretty hacky (saved the rule as a text string, wasn't translatable).

Custom fields (and paths, too) can now be read with owners.search and written with owners.edit. There's a description of a more complex edit (against paths) here, but the same general workflow applies to examining and updating custom fields:

Haha, okay. Let's just add a link to the transcript.

I guess the short of it is, I have rules to allow pushes, instead of rules to block pushes:

Ah, your underlying issue is difficulty understanding why pushes are rejected?

Should we maybe have the dragon also put a link to the relevant herald transcript?

Two aspects here, one or both of which may already be partially or fully implemented:

First: HeraldTestConsoleController is currently a big mess with a huge instanceof block.

Briefly, T9529 discusses some server-side system running on revisions that's live in your environment, presumably. Its current behavior is something like this:

sweet. I am sure we can work with those. I think Herald Actions in itself should work pretty easily in our existing workflow. I am very excited about server-side lint, but a bit more documentation about them would help me out. I can't understand it fully with your comments :)

I think T8405 and this are both basically discussing the same use case, which I understand to be:

Maybe slightly always ding a computer action vs. a human action. That is, if a human adds a subscriber, and herald adds a subscriber, that weight is (human action weight - 1), or something along those lines? Then if human adds a subscriber, but herald closes, the weight of the close action even though gets dinged, is likely still stronger.

In T9700#147847, @epriestley wrote:

The new tools from T9132 are now in HEAD (see D14718 for documentation, which will land shortly).

Upon rereading your description, I think these won't actually do what you want.

It is an intentional design decision that projects do not directly impact policies, and I have no plans to ever change this. In particular, I think the behavior when a task is in multiple projects is too confusing to ever be clear, straightforward, or easy to use. The projects may imply contradictory policies and users already have difficulty understanding policies without this additional complexity.

Instead, use Spaces, and change Spaces instead of changing projects to move a task between visibility areas. (Perhaps it would be helpful to think of Spaces as "Projects", and think of Projects as "Tags".) Spaces resolve the "multiple projects" issue by requiring that an object be in only one space, so the policy behavior is straightforward.

Actually, that report is already fixed.

Actually, that report is already fixed. For completeness, the behavior adapters should have is:

See also T7961, which is another modular behavior adapters should have.

• You can now technically write this as an extension by extending HeraldAction, although mail is quite complicated and this extension may be challenging to write.
• You could use an extension like the one in P1895 to add a comment instead, although I think this will be caught by notification preferences.
• You can use the action above (reject commit unless they bypass).
• You could use "Add Projects" and then just manually email the offenders who got hit at the end of the week to warn them.

Offhand, I'm inclined to still publish "Herald closed the task." in the "subscribe + close" hypothetical, which I think is the current behavior.

This behavior is "correct" in some sense (Herald really did perform the "strongest" action in the transaction group) but the sorting on tiebreakers is likely wrong (see D14680 for a similar case) and we should sort actions by real users over actions by Herald at the same strength.