GitHub Community
Replies: 35 comments 15 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.
-
|
@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.
-
|
My company prohibits https://github.com/refined-github/refined-github. Thanks for publishing these Javascript bookmarks that I can use as a workaround! |
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.
-
|
wow 2 years still not available? |
Beta Was this translation helpful? Give feedback.
-
|
Please help me. I am drowning in notifications of auto-created, already-merged PRs that I don’t really need to know about – but notifications I do need to know about are obscured by that deluge. This filter would be so useful. |
Beta Was this translation helpful? Give feedback.
-
|
All I want is a way to see the stuff that needs my attention. Merged PRs and closed PRs are just noise around the signal. I can't imagine anyone at Github actually uses the Notifications view. Otherwise the noise here would have been filtered out ages ago. |
Beta Was this translation helpful? Give feedback.
-
|
Please fix this. Being a high profile maintainer on GitHub is extremely dreadful if this isn't addressed |
Beta Was this translation helpful? Give feedback.
-
|
Hello. This is a desired feature for me as well. When I return from vacation or skip a few days of reviewing the notifications, they quickly become filled with merged PRs, so I'd like to have a quick way to delete those notifications. |
Beta Was this translation helpful? Give feedback.
-
|
I sincerely wonder if GitHub team is actually using GitHub to work on GitHub. This is such a basic requirement (i.e. mark all closed and merged as "done") that I just don't believe they do. If you don't - please tell us which competitor are you using, as it seems to be better for developer experience. But without jokes: we really need this. |
Beta Was this translation helpful? Give feedback.
-
|
Please for the sake of everything that's sacred add this feature, it's ridiculous how bad the current iteration of GH notifications are |
Beta Was this translation helpful? Give feedback.
-
|
What I was initially looking for in notifications was a way to view only open PRs. |
Beta Was this translation helpful? Give feedback.
-
|
+1 After some time away I now have ~200 closed/merged PRs to dismiss, while keeping open prs and issues to read. Can't seem to even get a filter that separates issues from PRs, it's a lot of manual work to use this notifications view. |
Beta Was this translation helpful? Give feedback.
-
|
I used Copilot to help write this simple Python script as a workaround: import requests
import os
# Set your GitHub personal access token as the value of the GITHUB_TOKEN environment variable
GITHUB_TOKEN = os.environ['GITHUB_TOKEN']
# GitHub API base URL
GITHUB_API_URL = 'https://api.github.com'
# Headers for authentication
headers = {
'Authorization': f'token {GITHUB_TOKEN}',
'Accept': 'application/vnd.github.v3+json'
}
def get_unread_notifications():
url = f'{GITHUB_API_URL}/notifications?all=true'
response = requests.get(url, headers=headers)
response.raise_for_status()
return response.json()
def mark_notification_as_done(thread_id):
url = f'https://api.github.com/notifications/threads/{thread_id}'
data = {'done': True}
response = requests.patch(url, headers=headers, json=data)
response.raise_for_status()
def main():
notifications = get_unread_notifications()
for notification in notifications:
print(f"Processing notification {notification['id']}")
if notification['subject']['type'] == 'PullRequest':
pr_url = notification['subject']['url']
pr_response = requests.get(pr_url, headers=headers)
pr_response.raise_for_status()
pr_data = pr_response.json()
if pr_data.get('merged'):
mark_notification_as_done(notification['id'])
print(f"Marked notification {notification['id']} as done (merged PR)")
if __name__ == '__main__':
main() |
Beta Was this translation helpful? Give feedback.
-
|
Updated the script, added concurrency: |
Beta Was this translation helpful? Give feedback.
-
|
I literally have 674 notifications on GitHub. This is unmanageable in a corporate setting. It's amazing how this is still not fixed since 3 years ago and we have to resort to running scripts hitting their API.
Can't get the script to run, throws a 404 for pr_url = notification['subject']['url'] |
Beta Was this translation helpful? Give feedback.
-
|
Apologize for spamming in multiple comments - I rewrote the code, let me know if this works for you: https://gist.github.com/keif/ece2fa9372d038f89a64ab14895ce462 |
Beta Was this translation helpful? Give feedback.
-
|
I rewrote the above script. It's not super fast - it took about two minutes to run through 500+ notifications. https://gist.github.com/keif/ece2fa9372d038f89a64ab14895ce462 |
Beta Was this translation helpful? Give feedback.
-
|
Praying every day that a PM at GitHub will pick up this feature request. The lack of status (open/merged/closed) filtering makes notifications borderline un-useable to me, and many others on large teams/orgs that get bombarded with notifications all day long. This has to be one of the most obvious improvements that GitHub could make to the notification system. As it is right now, it feels like a product feature that has been completely abandoned. |
Beta Was this translation helpful? Give feedback.
-
|
GitHub is too busy adding AI to everything, ignoring basic product principles. Come on. |
Beta Was this translation helpful? Give feedback.
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
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