Sure, we'd be happy to accept a patch for this.

The project/global version of this ("Send an email to...") probably should not override user preferences. The user version ("Send me an email") is always user-controlled.

Im kind of wary of Herald ignoring user preferences.

To your question @chad (although it seems like the clarity is not needed anymore), it just flags any newly created diff.

We are doing a policy check here, but it's an unusual check and it's not fully effective.

The expectation is that the rule will fail to run when the user can't see the object. The code is consistent with this expectation, looking into it..

This is definitely a T5791 thing.

I see your point and sounds fair for me.

Can you make a single call to some kind of middleware which looks up the token based on the callsign or ID, then submits the request to the build server?

We are providing different tokens for each URL.
And this parameter is not stored on Phabricator :-(

You can parameterize the URL, in a build step, e.g.:

Each rule has different parameters in steps. In our case it is different HTTP Request URL.

What kind of rules are you duplicating across repositories? Why can't these rules be expressed as a single rule which affects all the repositories?

We trying to automate Harbormaster + Herald setup for new repositories in our company (have plans to provide Harbormaster API methods soon). This method is required to check if specific rules are not created yet.

Can you walk me through your use case in more detail? We've never seen interest in this, and I can't come up with reasons why this would be useful offhand.

+1000 to improving serverside lint support. I have no problem with "can't
auto-change code" as the few uses of that we have have drawn some
complaints.

Michelle Sordal owns the agenda / schedule. Any dropbox folks should shoot her a note to get included on the action...! :D

hey! So I am in the security team at Dropbox. Would you have time to chat with some of us when you are at Dropbox next week? A lot of this might be easiest to figure out IRL.

Would love to see date fields supported.

Overall, we can definitely improve the transcript view, but it will never be an especially good solution to this problem:

that would be nice (maybe even ideal) if lint was actually a reliable thing
for us.

Suppose it worked like this:

there are plenty of cases where we do want a security review instead of
just lint warnings - it's definitely not as simple as converting everything
to lint rules. And part of the problem is that lint isn't expressive
enough - and in some cases can't possibly be.

It sounds like lint is a much better fit for this problem than Herald (for example, it won't raise warnings in comments, and it points out exactly where issues are, engineers get a chance to see issues before they get sent for review, etc) -- are there reasons it isn't that I'm missing, or reasons that moving these review rules to lint rules has been slow or impossible?

So I guess I should explain more about our use case.

Definitely lots that can be done to improve the ui here, but I'm most excited to learn what you do once you figure out why a given set of reviewers was added. (...I hope there's drama sometimes!)

In particular, at Facebook:

Do you think the majority of these blocking reviewer rules are good, or is figuring out why blocking reviewers were added more-than-occasionally the first step in removing them? If these rules added normal reviewers -- instead of blocking reviewers -- would this be a problem?

This is the most awesome feature request I've ever read. Well stated, sir.

Yeah, policy rules are a little muddy here. We should probably:

I suppose that the Herald Transcripts have a similar issue.

Yes, use a rule like this:

We don't offer email templates, there are other tasks you can follow for that. (T5244)

We need to change the contents of the mail sent for each action like audit, differential. we would like to add our own mail template.

Have you looks into the Owners tool? What specifically are you looking to accomplish?

I'm going to kick this off Phacility, since I don't think it's really a Phacility task (except maybe for monitoring, but that needs other work) -- yell if I'm missing something. We can drive this forward whenever, though.

Okay, thanks @epriestley!

It would be great if we know the ETA for the fix no matter soon or not soon.

It would be great if we know the ETA for the fix no matter soon or not soon.

In T7166#95831, @cburroughs wrote:

Is this the same as the herald based replacement for project mentions + email (T6819) ?

Is this the same as the herald based replacement for project mentions + email (T6819) ?

Hi Chad, Yes, without this fixed, we are not able to move forward for all tasks which need putting a project to CCs as a condition of the Herald Rule. Yes, it's up to your guys' priority list. But I hope this can be address very soon. Thanks!

Great, thanks guys. Can I recommend a small change in the text then:

Sorry, I'm confused. I read this to mean:

@chad is correct about how this works. "Any added file content" is new content across both existing and new files.

That's what my assumption would be.

Not quite because I want this to fire for changed files as well as newly added files.

Is this what you're after?

This issue isn't triaged or assigned. See T4778 for how we prioritize our time.

@chad, have you found the root cause?

@chad, I am glad you can reproduce it.

Oops, there was an error in my rule (match all vs match any) so I reran it. Still looks like a bug:

I built this here and was able to get a repro:

Can you list the complete steps to reproduce?

Anything I can do to faster the process to fix the bug?

In T7166#94790, @btrahan wrote:

sterling matches a user in remarkup, while #sterling matches a project. Did you verify the sterling in the subscribers section clicks through to the project and not some user also named sterling? (Or said differently, did you type sterling as initially reported (not a bug and probably due to the issue I am describing) or #sterling (a bug)?)

sterling matches a user in remarkup, while #sterling matches a project. Did you verify the sterling in the subscribers section clicks through to the project and not some user also named sterling? (Or said differently, did you type sterling as initially reported (not a bug and probably due to the issue I am describing) or #sterling (a bug)?)

See T6819 for some discussion of automatic associations.

It would be sort of cool if bugs+project@phabricator.com automatically worked, but I'm not sure if that is too much magic or conflicts with something else.

After checking with my team, the main need is to assign automatically the review to a specific team member because we know who will review the commits before coding.That's why we create a rule for each evolution to assign automatically the review to the right person.

T3670 will provide a cleaner and more general solution by letting you write one rule against the superproject (like #client) and have it automatically apply to subprojects.

Oops, I'm sorry. I'll try to explain better what my team and I are trying to do :

This report describes a solution instead of a problem. When filing a feature request, please describe the problem you're facing, not just your desired solution.

Interesting update (even if [perhaps not good news for this task):

That is correct. Right now, only commits which Ref or Close a Maniphest task associated with the project or which include the project's hashtag appear in the project feed.

I suppose what he's trying to achieve is to see all commits related to a project in the projects feed. (we spoke in irc)
And in some cases this might be all commits made to a specific branch.