0.00000000001 is very funny and we would be losing a truly great joke at such a young age

See downstream https://phabricator.wikimedia.org/T230001 for a similar issue on project pages.

To reproduce this easily:

Per D20533, the major query this UI uses is currently unkeyed (no dateCreated key on transaction tables).

The answer here is now pretty unambiguously "Use Webhooks". feed.http-hooks is formally deprecated, Herald remains a terrible idea, and anyone brave enough to touch Doorkeeper can probably figure things out for themselves.

No outstanding customer requests for this.

Changes connected to T13277 likely moot this. If users are pushing temporary personal branches to a repository, configure "Permanent Refs" to exclude them. Commits pushed to these branches will no longer publish feed stories, trigger audits, etc.

aaaannnndddd..... I found it. D19050

What steps did you take to try to find the documentation?

We currently use this extension at BisManOnline to integrate with our CRM system. Also, I believe that the Phabulous Slack Bot uses it as well https://github.com/etcinit/phabulous

I'm planning to build T11330 ("policy-blind" webhooks) instead, and deprecate feed.http-hooks. See that task for details.

In T5726#88706, @epriestley wrote:

One concern about this is that this information is policy-bypassing.

(I think D18132 should fix this once someone gets a chance to look at it.)

This came from D18028, when I changed the Include stories about projects I am a member of. checkbox to be a CheckboxesField. I think the issue is that existing saved queries may have the old value for the field stored (true), instead of the new value (array('self')). These queries would be impossible to construct in the UI now.

Hello, we used this function (add project to a commit by Herald rule) as well happily for about two years (last update of phabricator was 03/16/2016). The current phabricator update (06/06/2017) now lead to messages in the activity feed in the form of "Herald added a project to rXXXXX: <message>: <project>" and the commit itself (or better the message) does not appear anymore. When we disable the Herald rule the commit-messages appear in the feed again as before and expected.

This transaction uses shouldHideForFeed(), which isn't currently supported by Modular Transactions. It got swapped over in D17844 or some related change and we didn't catch that the logic wasn't firing anymore since this is a bit of an obscure case.

Thanks, this reproduces here for me.

Oh! If it's just a comment on an item, admins can remove comment on the drop down on the item and it should also be removed from feed.

You're likely right. I'll move down both corridors and see what I find. The system is fine.

I get what you're asking, but professionally it feels like you're trying to put a band-aid on a broken bone. It needs to be addressed. As admin you should be able to nuke most things from CLI or DB.

Bad hires are not a reason to ask the upstream to prioritize work. Even if feed had "delete" it doesn't solve the emails that already left the system.

Task deletion usage:
Colleague submits something for archival, but accidentally leaves in a bunch of dramatic content which does not reflect positively on hisself.

Anyways, let's just go with "See all" in the header for now.

I'm also not sure how that works with pagination, like, do you update the URL so people can send links?

But that sounds like a lot of work.

Basically what I'd like is something that auto-pulls maybe 5 times, then just makes you click a button thereafter. That solves the footer issue, makes it nicer for people who only want 2-3 more pages, and then the edge case of "no really I want to keep reading past 500 results" have to click a button.

Let me marinate on it.

Sure, we can do that too.

Isn't auto-scroll with lots of JavaScript the right answer?

Ah, that makes sense. If there's some "good enough" way to get a button/link into these things today I'm happy to drop that in place while I'm in here, but we can just leave it for fiddling later too.

I don't think the current feed UI looks good in blue header, which is why I haven't moved it over. I'd need to fiddle with feed-view

@chad, I'd ideally like to put a "view more" on the feed on the project page so that the original issue here (wanting to page back in history) is easier to solve. This is what it looks like right now:

It sounds like this is resolved.

After 6 month seeing the bug, i think i've found why it does that.

To move forward, we need complete reproduction instructions which we can follow to reproduce this issue in a clean environment. See Contributing Bug Reports and Providing Reproduction Steps.

Yep, this is no longer a problem with the new audit bucketing. 🏅

Particularly, see T9430.

Is that feedback based on the Audit dashboard at HEAD of master?

This would also be useful for the Audit dashboard, e.g. to build the query "what audits am I responsible for that I didn't author?" (given that the viewer belongs to a project which is responsible for auditing the commit).

Pagination isn't quite as simple as I'd remembered. Specifically, we do not expose internal pagination cursors to viewers today because doing so permits an information discovery attack that goes like this:

I think this behavior is very good

This is also a potential problem in the general case, although the general case of this is very rare.

Broadly, most applications can execute Spaces queries cheaply by querying ... AND spacePHID IN (<list of spaces the viewer can see>) when Spaces are configured, which is efficient until some install decides to create 30,000 Spaces for some reason.