I'm having some issues using the feed.http-hooks with the system I'm interacting with. My endpoint (trac) requires a CSRF token. I assume there aren't plans to add any sort of (even low-level support) for that? That's totally fine, this is kind of an edge case anyway.

This was resolved in conjunction with T8952.

Just reopening this so I don't forget about it since I agree about that last change.

I think this is reasonable to pursue, but I'd like to put the capability at the ApplicationSearch level rather than making it specific to one field in Feed -- basically, provide not(user) and not-viewer() or typeahead functions (or similar functions with better names).

In general some kind of batching (e.g. "Donald commented on T### , approved D###, did it N other actions, click to expand") would also address this, but a view level filter seemed like an easier ask

We haven't seen other confusion about this in context.

Like just don't show it at all? That seems reasonable to me, although 0.00000000001 is very funny and we would be losing a truly great joke at such a young age.

maybe herald adding a subscriber is truly 0 then as a feed story.

That's because it was deliberate self-subscribe which is so completely boring that we normally wouldn't even show it. I think it's arguably correct to show the Herald story? Maybe?

This is an emergency.

Deliberate Subscriber + Herald Subscriber = Herald Subscriber Story.

very nice

seems ok to me.

I think that story strength thing is non-retroactive? This may not really be fixed if new stories aren't better.

There's some level of magical heuristic, so yell if you still see issues.

Closing for lack of feedback. Specifically we'd need to know exactly how to reproduce this locally before attempting any fixes.

From T10822, we currently choose [Changed Subscribers] as a stronger action than [Merged] for tasks in some cases in email subject lines. This is probably not the correct heuristic, [Merged] is normally a strong action.

Technically, the feed story is correct.

See also T5381: Provide RSS feed of changelog (I'm not sure if identical/mergeable)

Awesome! Thanks for the quick reply @epriestley :)

See T5726, T10363.

The data available from feed.http-hooks or feed.query is somewhat limited:

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.

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.

Probably can try to install bc and report back if you still see it. What MySQL version are you running?

@avivey: 32bit, yes, no
and the error just went away...

Feed Story's getEpoch() is doing some serious magic: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/feed/storage/PhabricatorFeedStoryData.php;20e6a4200dbc72760ea5de4eb15053bc1b2c8dac$41

it looks like maybe Feed tried to combine the transactions, and got something wrong?

I think the right solution is to offer more options on what people see in feed, not outright removing items (at an admin level).

Oh, yes the "Herald" as the actor is incorrect.

This is displaying as intended. That is, if there is no image available, we still outline the actor space for consistency.

Seems resolved in the example. This is not 100% completely perfect yet (there's still some cruft kicking around) but I think it has no user-facing impact anymore.

One story is a task that is closed, the other is a commit.

This seems to be stable now, I don't immediately see any more ridiculously dumb slow stuff in the /feed/ profile. Remarkup handle fetches are still a bit loopy but that's a topic for another task.

Is there a way to query the notification feed (https://secure.phabricator.com/notification/) using the conduit API or something? I have built a notifications app for windows that currently works off scraping the HTML on that page since I cannot find a suitable API for it.

We don't plan on pursuing this in the upstream. Mainly, it affects too few people, and in ways that are duplicative of other Phabricator features. The core team wouldn't be able prioritize building something like that. There is no reason a third party couldn't build this and offer it on Community Resources if interested.

RSS feeds have a clear use-case: that of viewing recent events at a dozen of websites without visiting each of these web sites by hand and without spamming email with messages I don't intend to reply to.

Another example is tasks. We create columns for work requests on the Workboard for projects and then outline the work request in multiple tasks. We've had work request with 20+ items. This fills the feed really fast. Especially if you forget to set to assign the tasks or something and have to go back in and make changes. Each of those changes then shows up in the feed as well.

Can you provide more examples of feed stories that you'd like to delete? Generally, I think the goal we want to solve is to make feed useful such that you don't feel the need to X out stories, so more context on what you want to remove is very helpful. In the example given, I would think we might want to aggregate those stories and just show a single one.

Fixed it for me, thanks!

Let me know if that didn't fix it ^^

I'll see if I can guess what's going on here; otherwise maybe I'll just sneak a look at things the next time I'm over there.

I can't load up Paste period, so not a project feed thing.

its on my cloned install, hmmm... no idea what maybe didn't make the mysqldump

I made the "likely" edits locally without hitting an issue: