Show all issues, not only the ones assigned to you

[bfelbo]

This looks amazing! However, for some repos I'm the only developer and I'd like to just see all the issues instead of having to first assign them all to me. This seems like a simple feature to implement?

[halcyondude]

+1, am I missing a setting?

[jhpratt]

@chrmarti Looks like it should be as simple as adding a checkbox in the settings to toggle this line. Would a PR be accepted?

[chrmarti]

@jhpratt Sounds good, PR appreciated!

[Stephanevg]

Any news on this guys? I am super interested in this feature.
CC @chrmarti

[jhpratt]

@Stephanevg I'll get around to it at some point; it's by no means a priority of mine though. I've never touched a VS Code extension, so I honestly have no idea how to add in a checkbox.

[pmrt]

I was working on a PR for this but unfortunately it requires some changes:

vscode-github-issues-prs/src/github-issues-prs.ts

Lines 296 to 310 in 8bca254

	const params = {
	q: `is:open assignee:${assignee}`,
	sort: 'created',
	order: 'asc',
	per_page: 100
	};
	const items = await fetchAll(github, github.search.issues(<any>params));
	return items
	.map((item: any) => ({
	item,
	remote: remotes.find(remote => item.repository_url.endsWith(`/${remote.owner}/${remote.repo}`))
	}))
	.filter(({ remote }) => !!remote)

Here we're fetching all the issues (visible for the provided Github account) and then filtering the results by repository. The problem is if we change params.q to something like this:

let q = 'is:open';
const params = {
	q: this.showAll ? q : q += ` assignee:${assignee}`,
	order: 'asc',
	per_page: 100
};

When params.q = 'is:open', we're fetching all the issues visible for that account, which basically boils down to.. all issues in all the public repositories in the whole Github website. Yep, not good.

I suggest opening a new issue to change how it fetches all issues. Instead of fetching all first and then filtering the results, it should fetch only the ones for the repositories (ie. remotes) we need.

I found this method: issues.listForAuthenticatedUsers() in the library that this project is using. It lists all issues which the authenticated user owns or is member of.

Maybe this method github.issues.listForAuthenticatedUsers() (with slightly different signature) fits the project better than github.search.issues() here?

vscode-github-issues-prs/src/github-issues-prs.ts

Line 303 in 8bca254

const items = await fetchAll(github, github.search.issues(<any>params));

What do you think? cc @chrmarti

[chrmarti]

listForAuthenticatedUsers() might be an optimization for the current query. Note that we later filter by repository (remotes parameter in this function).

To implement showAll you might need to run fetchAll for each repository. I originally did that and then realized that this runs into GitHub's rate limit for queries much earlier. It might still be the right thing to do here and it will work well when the list of remotes is not too long (it will usually be a single remote). I'd suggest adding an if (showAll) { /* multiple queries */ } else { /* existing query */ }.

[pmrt]

Exactly.

To implement showAll you might need to run fetchAll for each repository

Yeah, that was my point. But just with the current implementation, not with listForAuthenticatedUsers(). The problem here is we're using search.issue() and thus fetching all visible issues [for the user] in the whole github, filtering by assignee. When we don't filter by assignee we get all visible issues [for the user] in the whole github (what turns out to be all issues of all public repositories). So yeah, by using search.issue() we would need to filter by the provided repositories (remotes), which would lead us to run fetchAll for each repository.

But by fetching with listForAuthenticatedUsers() instead, we're already filtering by repositories the user owns/is member of (and then filtering the results again by the provided repositories in the remotes parameter), so we would fetch in one round trip all visible issues of just the needed repositories.

To sum up we have two options:
A) Open a new issue to change the implementation of fetchAllIssues()using issues.listForAuthenticatedUsers() instead of search.issues(). Once it's finished, tackle #41 (this one)
B) Keep the current implementation with search.issues() and just like @chrmarti suggested: if (showAll) { /* multiple queries */ } else { /* existing query */ }. This is the easiest and fastest way.

IMHO I'd recommend to go for A.

[chrmarti]

I think issues.listForAuthenticatedUsers() with filter: 'all' would return too many issues for members of large projects (e.g., VS Code).

[pmrt]

Yeah, that's right. However, that's the point of this issue, to show all issues right? I mean, if you're member of large projects you wouldn't want to enable this feature anyway because you'd get lost with so many issues.

What about limiting the results to X pages to avoid performance issues? That way instead of checking with a if (showAll) each iteration of fetchAllIssues() we would just fetch the results, limiting excessive amount of pages which could cause performance issues. Is there any use case where the user needs the extension to display +200-300 issues?

If you can't find the issues you want you just provide the repositories you need in the configuration or just don't enable this option.

[chrmarti]

You would still want to filter by the list of remotes (a parameter to the function) that are of interest. So, there might be only a single remote of interest (e.g., the current repo's origin) and only a handful of issues, but you might not see all these issues if they are on a later page of this large query.