Color-code issue & pull request icons based on status

[c-lliope]

It would be great to see closed issues and PRs displayed with a red icon, and merged PRs displayed with a purple icon. If I'm scanning a large number of notifications, that would help me prioritize which ones are important to view vs ones I can dismiss.

I love the project! Best way to view github notifications that I've found yet. Keep up the good work!

[laughedelic]

+1

[cbarraford]

I started working on a PR that would do this (and got something mostly working), but theres a problem. Currently the api access scope of gitify is notifications and user email addresses. In order to get the state of a pull request or issue, etc, you need api access to the repo (which obviously mean access to the code and everything else). Would people be ok with this? Would there be a revolt against the idea of giving gitify access to more data/info in your github account? @ekonstantinidis curious to get your standpoint on this.

https://developer.github.com/v3/oauth/#scopes

[manosim]

First, I've got to say that this sounds like an awesome feature to have! So thanks for opening the issue @Graysonwright and for working on that PR @cbarraford!

Can you give me some more info about the changes?

• Moving the scopes from 'user:email', 'notifications' to ?
• Do we need an additional request to the GitHub API?

It would be great to have this feature 👏

[cbarraford]

@ekonstantinidis

The scope change would be....

- scope: ['user:email', 'notifications']
+ scope: ['user:email', 'notifications', 'repo']

It does require an additional GitHub API call every time we get a list of notifications that is either an issue or pull request (to get the current state of the issue/pull-request). So if we refresh the list of notifications and there are 1000 pull request notifications, we'd make 1000 independent api calls.

[manosim]

It would be better if there was a repo:read only scope but I guess we can deal with it. About the additional request - is it going to be one more request, no matter how many notifications there or one request for each notification that's an issue/PR?

[cbarraford]

one request per notification that is an issue or PR (unless theres a way to do a batch api call that i'm not aware of)

[manosim]

That's something that I'm not sure about - If someone has 30 notifications - the worst case would be that the app will make 30 more requests to the GitHub API which we should avoid 😢 Any opinions on this one?

Ps. I'll investigate to see if we can send an array of notifications to the GitHub API which will be a saver.

[cbarraford]

we could use this API endpoint and get a list of all issues that are open (across all repos). Anything not in that list is consider closed.
https://developer.github.com/v3/issues/#list-issues

For PR we could list open PRs for each individual repo. But we wouldn't know which PRs are merged vs closed. So you may need to do 2 api calls to get closed PRs.
https://developer.github.com/v3/pulls/#list-pull-requests

With this approach its (1 + (numOfRepos * 2)) more api calls.

[manosim]

Looks like this has to do with the GitHub Api so for now we can just wait for an updated API. Will reopen if anything changes.

[ericboehs]

In day to day use I usually only have 1, maybe 2 unread notifications at a time. Even over night I don't usually see more than a few. And I watch several repos.

I think the extra information is worth the extra HTTP calls. Perhaps we could limit it to 10 calls and fallback to the current functionality.