Show "open" notifications

[ajdubovoy]

I'm so appreciative this exists!

As with probably other Github users, I don't really organize my notifications by whether they're unread or not. If I'm done with a notification, I mark it as "done".

As far as I can there's no way in this extension to search for "is:open" notifications. It would be awesome to have:

1. A way to show "is:open"
2. A way to show "is:done"
3. A way to mark a notification as open/done

Thanks so much

[LangLangBart]

A way to show "is:open"

• This could be done by implementing a filter that checks if the notification is a PR/issue and then checks if it is still open.
• The downside
  • notifications retrieved from Github do not contain the information about the status of a PR/issue, you would have to make an additional call for each notification, which would cost time
  • I would love to have color coded notifications
    • green: open
    • red: closed
    • purple: merged
  • Image example from another extension

• Related threads
  • Get notification list via GraphQL API - 13/Mar/19
  • Can't get release neither comment using their id via GraphQL API - 7/Oct/19
  • Notifications GraphQL API - 19/Mar/22

A way to show "is:done"
A way to mark a notification as open/done

• GitHub does not provide this functionality through its API
• Related thread
  • Expose notification mark as done functionality through API #15669

---

Conclusion

• Implementing your ideas depends more on GitHub's API.
  • Filtering notifications for issues/PR and checking if they are still open is worth a try, leaving the ticket open for now.
  • it could be added as an additional flag, allowing the user to decide if they prefer speed or more details

[ajdubovoy]

Thanks so much for the considered response! With the is:open filtering I meant that the notification has not been marked done (not that the associated issue or pr is still open, if applicable).

It's wild that they don't provide access to this in the api but do to lots of other details about notifications.

Anyway, the color coding is still a lovely idea and I so appreciate your work on this

[LangLangBart]

When interacting with the GitHub WebUI, one can see the API calls being made from the Inspect page on the Querio tab (ref: querio.app). The call to mark notifications as Done is possible, but it does require an additional authenticity_token.

---

I'm closing the ticket for now, as GitHub does not readily allow the required API calls and no one knows when these undocumented API calls will be made available to the public without using an authenticity_token. Also, generating these authenticity_token doesn't seem to be possible, I couldn't find a way to generate them.

---

as for the other idea:

Filtering notifications for issues/PR and checking if they are still open is worth a try, leaving the ticket open for now.

I tested it, but I quickly got rate limitations when I made many calls with in short succession to check the state of each issue/pr. A GraphQL API for GitHub notifications would be great.

[rmacklin]

Re:

A way to mark a notification as open/done

• GitHub does not provide this functionality through its API

Is that not what this is:
https://docs.github.com/en/rest/activity/notifications?apiVersion=2022-11-28#mark-a-thread-as-done
?

[LangLangBart]

Re:

A way to mark a notification as open/done

• GitHub does not provide this functionality through its API

Is that not what this is: https://docs.github.com/en/rest/activity/notifications?apiVersion=2022-11-28#mark-a-thread-as-done ?

This appears to be a recent addition to the REST API. According to the Wayback machine, the
feature to Mark a thread as done was introduced somewhere between June 10, 2023¹ and February
5, 2024².

Did you discover the changelog for such updates for the REST API? Although there is a readily
accessible list of updates for the new additions to the GraphQLAPI³, I was under the impression
that no such resource existed for the REST API.

---

I am considering adding a hotkey to mark notifications as DONE, which would equivalent to marking
a notification in your notification inbox on GitHub as DONE. However, the challenge lies in the
fact that the Terminal would continue to display the same list, as the data does not reflect whether
a notification is DONE or not.

For instance, the notification I received from your comment carries the following information. Even
after marking it as DONE, the returned data remains unchanged. Therefore, pressing the hotkey
wouldn't convey any noticeable changes to the Terminal user. They would only become aware of the
change upon logging into their GitHub account and checking their inbox.

{
"id": "6463980195",
"unread": false,
"reason": "state_change",
"updated_at": "2024-03-02T23:54:38Z",
"last_read_at": null,
"subject": {
	"title": "Show \"open\" notifications",
	"url": "https://api.github.com/repos/meiji163/gh-notify/issues/47",
	"latest_comment_url": "https://api.github.com/repos/meiji163/gh-notify/issues/comments/1974945563",
	"type": "Issue"
},
...

---

I would prefer to wait until Github introduces a new field for conveying the information, with a
done: true/false status.

Footnotes

1. https://web.archive.org/web/20230610191811/https://docs.github.com/en/rest/activity/notifications?apiVersion=2022-11-28 ↩

2. https://web.archive.org/web/20240205034519/https://docs.github.com/en/rest/activity/notifications?apiVersion=2022-11-28 ↩

3. GraphQL API Changelog - GitHub Docs ↩

[rmacklin]

Thanks for the detailed reply. Yeah, I see your point about not wanting to implement this if we can't distinguish the "done" items. It's quite frustrating that there's no property in the notification's JSON indicating that it was marked done (or saved for that matter) even after adding the "mark as done" API. Not sure why the API doesn't let us pass query=is:done like the web app does.

[sitano]

edit: oh, now I see read feed.

Why do we need to distinguish is:done entries if they are DELETED with the done action? so they are no appear in the notifications feed. #91 works great for me. See --method DELETE https://github.com/meiji163/gh-notify/pull/91/files#diff-d286f9120037bbf01847f2c1283501f4a44c6943ee65ed1783edf64088f2b584R553.

[sitano]

it seems the status is:read can be distinguished by checking 2 fields in conjunction unread == false && last_read_at != NULL whereas is:done have last_read_at == NULL, like in:

  {
    "id": "11615952375",
    "unread": false,
    "reason": "review_requested",
    "updated_at": "2024-07-23T10:46:01Z",
    "last_read_at": "2024-07-23T13:38:55Z",
    ...
  }

this is done

  {
    "id": "11615952375",
    "unread": false,
    "reason": "review_requested",
    "updated_at": "2024-07-23T10:46:01Z",
    "last_read_at": NULL,
    ...
  }

[sitano]

btw, for git notify -a I think it needs a page limit (not to load everything at once) cuz every reload is painful.

[rmacklin]

it seems the status is:read can be distinguished by checking 2 fields in conjunction unread == false && last_read_at != NULL whereas is:done have last_read_at == NULL

I'm not seeing the same. I have many notifications that have been marked as "Done" in the web UI which still appear in the API as "unread": false with a non-null last_read_at.

The only time a notification would appear "unread": false with a null last_read_at is if you mark it as done without ever having opened that object. Even if you get a new notification for the same issue/PR/etc that you had previously opened, but you do not open it again, it will still have a non-null last_read_at (both before and after marking it as done without opening it).

So unfortunately, it doesn't seem like check would work for correctly distinguishing "done" notifications.

[sitano]

@rmacklin you are right. I confused that a bit.