GitHub Community
Replies: 19 comments 12 replies
-
|
I was about to add the same feedback—even adding only "is:open" and "is:closed" filters to the Notifications inbox (i.e. #12410) would change everything for my teams. Our use case: Some teams would like to have a way to easily see all open PRs that their team has been requested to review, even after all review requirements have been met. The current CODEOWNERS implementation, however, removes the team review request once review requirements are met (via individual reviews by subset of team members) (cf. #5289, #16853). This means that some team members won't notice PRs that can still be reviewed. As a current workaround for this behavior, these teams have resorted to listing individual team members in the Today, we have a way to see unreviewed open PRs assigned to a team, though they disappear from this view once review requirements are met. The Notifications inbox, on the other hand, provides a way to see all PRs where your review has ever been requested regardless of review status, but there is currently no way to filter out merged/closed PRs. (Hence this feature request.) I hope this is clear, and I look forward to seeing a solution—thanks! |
Beta Was this translation helpful? Give feedback.
-
|
Closed #12410 in favor of this discussion.
|
Beta Was this translation helpful? Give feedback.
-
|
Most people in my org will ignore the website's notifications because it lacks this feature. |
Beta Was this translation helpful? Give feedback.
-
|
Trying to use an inbox-zero type workflow is pretty difficult without a |
Beta Was this translation helpful? Give feedback.
-
|
I don't use GitHub notifications for this reason. The vast majority of my inbox is PRs that got reviewed, approved, and merged, and therefore are not relevant for me anymore. And because people (understandably) tag the whole team for review so the first available person steps in, the only way for me to control this signal to noise ratio is on my end. Ideally the notifications feature would just cancel notifications that are no longer relevant (like reviewing a PR which you were not personally requested to review and which is already merged). But, since that kind of opens a UX/workflow can of worms, the next best (or maybe actual best) solution is definitely to let people clean up their inbox using such a filter. Because right now, the inbox is basically useless. Just a infinite list of ignore-able purple merged icons. |
Beta Was this translation helpful? Give feedback.
-
|
I want to call extra attention to the amount of noise this would eliminate. I currently have 219 notifications. Clearing them is an insane chore.
The most frustrating thing is this:
Those little indicators are taunting us. We can see that the notifications system has all the metadata it would need to let us filter this way. It's right there. Very, very rarely is it safe or sensible to speculate about somebody else's code, but in this case, a desperately-needed QoL feature is tormenting us every time we click the bell. |
Beta Was this translation helpful? Give feedback.
-
I'm ashamed to say this but there's now a stinky function/alias in my zsh configs just to place these in my clipboard. I had to change the |
Beta Was this translation helpful? Give feedback.
-
|
@condekind @aukehuizinga @githuolivier-abdesselam @pvinis Improvement : add canceled issues, closed PRs, and // Closed issues select
Array.from(document.getElementsByClassName("octicon-issue-closed")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});
// Canceled issues select
Array.from(document.getElementsByClassName("octicon-skip")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});
// Merged PRs select
Array.from(document.getElementsByClassName("octicon-git-merge")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});
// Closed PRs select
Array.from(document.getElementsByClassName("octicon-git-pull-request-closed")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});
// Done button click
document.querySelectorAll('button[type="submit"][data-hotkey="e"]')[0].click();Starting from page 2 or 3 of notifications is usually faster Bookmark version : javascript:Array.from(document.getElementsByClassName("octicon-issue-closed")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});Array.from(document.getElementsByClassName("octicon-git-merge")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});Array.from(document.getElementsByClassName("octicon-git-pull-request-closed")).forEach(function(bla){bla.parentNode.parentNode.parentNode.parentNode.getElementsByTagName("input")[0].click()});document.querySelectorAll('button[type="submit"][data-hotkey="e"]')[0].click();NOTE: updated on 2024-03-13 (done button change on GitHub) |
Beta Was this translation helpful? Give feedback.
-
|
So good I found this thread! Extra note: Github Product team really, shame on you guys, wtf! |
Beta Was this translation helpful? Give feedback.
-
|
Such an awesome suggestion for a workaround. Here's my iteration of it with slightly smaller implementations: Closed Issues [...document.querySelectorAll('.notifications-list-item:has(.octicon-issue-closed)')].forEach(el => el.querySelector('input').click());Canceled Issues [...document.querySelectorAll('.notifications-list-item:has(.octicon-skip)')].forEach(el => el.querySelector('input').click());Merged PRs [...document.querySelectorAll('.notifications-list-item:has(.octicon-git-merge)')].forEach(el => el.querySelector('input').click());Closed PRs [...document.querySelectorAll('.notifications-list-item:has(.octicon-git-pull-request-closed)')].forEach(el => el.querySelector('input').click());Personally I've made each of these their own bookmarklet, and another that has them all. Again using the Edited to make it easier to copy each of the snippets. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for pointing out https://github.com/refined-github/refined-github has this feature. It's been bugging me ever since they released these "new" notifications that this isn't possible. |
Beta Was this translation helpful? Give feedback.
-
|
Agree. It's currently a big headache going through a bunch of already resolved notifications. This would be a major improvement 👍 |
Beta Was this translation helpful? Give feedback.
-
|
This feature is so obviously missing and experience-breaking that I can only guess there is some infrastructural reason GH wants to limit this query. Not holding my breath but it really does make the page unusable for me which is sad. |
Beta Was this translation helpful? Give feedback.
-
|
I need this feature. |
Beta Was this translation helpful? Give feedback.
-
|
One begins to get the impression GitHub switched its forums to Discussions so that we’d all complain into the void without expecting results. This is too old to have been missed, too obvious not to accept, and yet no response. Either there’s nobody to triage it over to, or they’re not gonna pick this one up. |
Beta Was this translation helpful? Give feedback.
-
|
Please stop "bump"ing the thread, you're spamming subscribers that want to get updates to the discussion. You're adding nothing by bumping it. |
Beta Was this translation helpful? Give feedback.
-
|
To add a bit of education to the scolding (and unfortunately spam everyone yet again, but hopefully this time it results in less overall spam due to the education), you can show your support for an issue by clicking this:
at the bottom of the original comment. As you can see, 88 people have done this rather than spamming all of the subscribers of this issue with annoying bump messages. |
Beta Was this translation helpful? Give feedback.
-
|
GitHub Discussions’ default sorting is by recent activity. Users bumping this thread move it back to the front page, where it currently is. Since this is now GitHub’s only public-facing feedback mechanism, the inclination to bump for visibility is understandable. |
Beta Was this translation helpful? Give feedback.
-
|
Hello, I've noticed that we can apply a filter to select specific statuses only. However, it seems that we're unable to execute bulk actions with this filter. When I clicked on 'Select all 202 notifications,' it ended up selecting all notifications instead of just the merged ones. Consequently, this filter doesn't prove to be very useful when dealing with a large number of notifications. 
|
Beta Was this translation helpful? Give feedback.
-
|
This is a feature added by Refined GitHub, maybe you can ask this there? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, you're sure 😅 Issue on GitHub side still exists. |
Beta Was this translation helpful? Give feedback.
-
|
I've stumbled upon this discussion as I wanted to start using notifications properly and with initial count of over 1200 notifications (most of which were closed pull requests from dependabot) without this kind of filter it seemed impossible. I finished with writing this tiny
octokit.paginate("GET /notifications").then(async (notifications) => {
let modified = 0;
for (const notification of notifications) {
if (notification.subject.type === "PullRequest") {
const { data: pr } = await octokit.request(
`GET ${new URL(notification.subject.url).pathname}`
);
if (pr.state === "closed") {
await octokit.request("DELETE /notifications/threads/{thread_id}", {
thread_id: notification.id,
});
modified += 1;
}
}
}
console.log(`Marked ${modified} notifications as done`);
});Which after few minutes left me with less than 400 notifications. Then I've modified it to delete all notifications related to commits and releases and I have just over 150 pieces that I can manage by hand. Maybe somebody will find this useful. |
Beta Was this translation helpful? Give feedback.
-
|
I've also made some simple template repository with GitHub Action that will run script from above here: https://github.com/SPodjasek/notifications-bulk-update-template |
Beta Was this translation helpful? Give feedback.
-
|
Seeing this feature request still being totally ignored after so much time and upvotes sounds like GitHub teams doesn't even use their own tool at all. |
Beta Was this translation helpful? Give feedback.
-
|
Seriously what a huge amount of wasted time...this is such an essential feature |
Beta Was this translation helpful? Give feedback.
-
|
Please support this. I would actually use the notifications page if this worked. |
Beta Was this translation helpful? Give feedback.
and others
-
Hey there, daily I review my work notifications from GitHub, and a feature that would be interesting is filtering notifications(PRs and issues) by status. I mean
open,closed,mergedby status. It would be interesting to have more agility when working on reviewing activities on my work projects.This image can help understand what I mean:
For example, in the case of this image, I need to scroll and search for closed activities(PRs and issues) on the repo that I'm working on. Still, today is painful because I need to use pagination and memorize which ones I already viewed to close appropriately.
Thanks in advance and for improving a lot this service :)
Beta Was this translation helpful? Give feedback.
All reactions