You want to specify projects based on Repository and Branch?

Let me take another crack at a concise problem statement:

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/ covers a bit more in detail about what we're looking for in feature requests. Specifically, just tell us the problem you are having with Phabricator and we can look to generalize a correct solution.

I went so far as to re-install Phabricator from scratch and was able to successfully fully import the Phabricator repository again.

We had no herald rules it was a clean start.

Yes, everything is fine. Just an FYI that importing the commits into Phabricator is done via the various worker parsing...

The issue is not to import the commits into phabricator. But when the workers start to parse the commits for "whatever". If you go to the deamons task list is everything fine ?

I do not know how to reproduce this issue as reported. For example, I import the Phabricator production instance into my local dev install. I do have a btrahan account there, but otherwise there is no user account overlap. Commits seem to import fine:

We would really appreciate this!

Not showing an indicator for the empty state is a bit inconsistent with other production decisions, but my reasoning was that if we always show "<author> already signed stuff" then 99% of diffs (i.e., those created by repeat users) will have it and it won't be useful on them. This felt a bit more like a warning that we only need to show when there's a problem to me.

Ah ok, I thought it'd still be attached (but state signed or something).

The author has already signed the agreement. The rule has no effect for authors who have already signed.

https://secure.phabricator.com/herald/transcript/62438/
https://secure.phabricator.com/D11007

In particular, "Changed Files" will include all the content, because all of the files have changed -- they were previously empty, and now they have a lot of content.

Copying a file creates a new file, so this is working as expected. The diff is not empty: it adds all the copied files.

Thanks!

Support Impact I haven't triaged, but this looks like a bug with no recourse.

Putting this upforgrabs... I think this is something we should build ASAP after getting Phacility out the door.

Closed by commit rP3d2e03d0e2f7.

Well since I get to ignore implementation difficulty:

• A way to say 'only try to evaluate herald rules on commits in these branches' (sort of like the auto-closes configuration).
• Fancy constraint system only re-evaluates rules that possible could be affected by branch moves (so if you have no rules that reference a commits branches nothing happens).
• Use knowledge of history to only re-evaluate commits since the branch point in the "temp-devel-bufix" case.

We had a similar problem (tracking feature branches and triggering a herald rule when a commit shows up in master) and solved it by specifically looking for the merge commit in the master/production branch.
Depending on what your herald rule does it might be necessary to apply an action to every commit contained in a merge commit. I'm not sure what happens if you trigger an audit on the merge commit. It might include more commits than what you want.

Closed by commit rP8e1a4eef0400.

I'm just going to merge this into T5604, I think it will be hard to do that without getting this at the same time.

Putting this upforgrabs as its just blocked on T5604 now and otherwise works. (i.e. Maniphest doesn't work everything else does.)

This is expected, although not necessarily intuitive or well-explained, and maybe not desirable. "Commit's branches contain" really mean "Commit's branches [at the time when Herald executes, shortly after initial discovery] contain".

See T4666 for a more general overview of Herald.

Herald allows users to write rules which react to changes in objects they care about (for example, by notifying the user of the change). We'd like to support Phriction (the wiki) in Herald, so users can easily monitor changes to wiki pages. (One example use case is that I'd personally like to be notified about any edit to any wiki page on this install).

I guess this request is more relevant for the open source community case than for the corporate intranet case:

T436 was another related task which rolled into T402, but roughly was a request for the ability to set reminders. I haven't seen other requests for that since then, but Calendar + time infrastructure should give us reminders for free/cheap.

See also T402, which I'm just going to close and point here since it's ancient.

Haha, yeah, I thought of that too. In short, it was this little robot at Facebook built by @jeg that would ping tasks - "you haven't touched this in X. do something or we reap it at Y" - and then reap 'em. (@jeg - feel free to embellish...! =D )

I smell a Task Reaper (cc @btrahan).

In T6465#82339, @chad wrote:

Our datasource typeaheads are all able to be called without javascript. For example, the repository typeahead (like in your Herald image) is here:

https://secure.phabricator.com/typeahead/class/DiffusionRepositoryDatasource/

Or as JSON:

https://secure.phabricator.com/typeahead/class/DiffusionRepositoryDatasource/?__ajax__=true

I don't know if @epriestley has other thoughts, but sounds suspiciously like your webserver is sending the incorrect JS files, or old JS files (either by caching or other mechanic).

We don't even use getPreventDefault that I can find. https://github.com/phacility/phabricator/search?utf8=%E2%9C%93&q=getPreventDefault&type=Code

Nop, versions are

Are you using Beta browsers?

We have two errors while inspecting the element. Checking on this

Ok, we shall check this.

Our datasource typeaheads are all able to be called without javascript. For example, the repository typeahead (like in your Herald image) is here:

Ok, Chad. We shall continue to figure it out. Thanks for your support.

Unfortunately, we cannot reproduce this and have no other reports right now. Happy to leave this open, but we don't have any additional thoughts. See https://secure.phabricator.com/book/phabricator/article/feedback/#unreproducible-problems for more information.

Yes. Typeahead is coming with Maniphest and other tools. It was working prior to the up-gradation of phabricator installation on October 24 around 3 a.m EST.

We also want this!

and Herald is the only Typeahead you are having issues with?

Thank You,
*UNAIS A*
Cloud Engineer

Hi Chad,

I don't have any other ideas. I'd try the following:

Thanks for looking into this, Chad. I think this is not a browser issue. I am able to see the suggestions on a local installation using the same browser

BTW, this is something that we'd like to request as well -- our primary use case is that our developer relations people want to get alerts whenever we fix bugs in our API so we can notify the affected developers. Do we have any sort of an ETA on this?

Nope, this was solved by recent changes and now all Herald-rule marked commits have nice orange "Audit Require" badge on them.

Does this issue still exist?

Yep, all yours.

(whoops, I don't know why I selected "resolve" and not "reassign")

Cool if I yoink this? Yoink back if you're working on it.

Support Impact Inconsistent and confusing, although mostly fixed now.

Closed by commit rP5f8280506862.

(There's some fuzziness with the ruleset right now; I believe you can see the effects of their rules in transcripts, for example. Herald predates policies and is generally awkward to balance cleanly against them. There are things we could do better, but I think the major interactions are working correctly today.)

It's expected that you can't see other users' personal rules. Administrators can't violate policies, and users' personal rules are private.

One thing I do think could help, and maybe I'm just being an idiot. If I create a global rule as an admin, and then a non-admin user creates a personal rule. On my test installs I see both rules as the non-admin if I go to http://fabapi.wmflabs.org/herald/query/all/ but only the global rule as the admin. That seems weird? I would expect to see the same rules in both cases.

I think separating this policy out is also probably worth doing eventually, but it looks like it doesn't solve any immediate problems.