{{ message }}
Repository navigation
Color-code issue & pull request icons based on status #154
Description
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!
Activity
laughedelic commentedon Mar 6, 2016
+1
cbarraford commentedon Mar 8, 2016
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 commentedon Mar 8, 2016
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?
'user:email', 'notifications'to ?It would be great to have this feature 👏
cbarraford commentedon Mar 8, 2016
@ekonstantinidis
The scope change would be....
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 commentedon Mar 8, 2016
It would be better if there was a
repo:readonly 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 commentedon Mar 8, 2016
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 commentedon Mar 8, 2016
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 commentedon Mar 8, 2016
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 commentedon Jun 7, 2016
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 commentedon Jun 7, 2016
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.