Support GitLab groups/subgroups when querying API for projects/issues

[Nezteb]

Problem Statement

I'm trying to set up the GitLab.com integration, and my current settings aren't working no matter what values I use. In this case, my company's GitLab org (we'll call it company) has a backend-team subgroup.

❔ Possible Solution

Regardless of what "source" I set, the app tries to call the /projects/<group>/issues endpoint. From what I can tell, the official GitLab API docs don't mention that specific endpoint: https://docs.gitlab.com/ee/api/rest/index.html

If you instead use the /groups/<group>%2<subgroup>/projects (the %2 is important) endpoint to get a list of projects and then iterate over that list of project IDs, you could get the issues from the /projects/<id>/issues endpoint.

⤴️ Describe alternatives you've considered

I've also tried just using the top-level group for the company, but that doesn't seem to work either.

➕ Additional context

Relevant existing/closed issues and PRs:

• Link GitLab group #697
• Allow Group and All scope for gitlab #1560

[github-actions]

Thank you very much for opening up this issue! I am currently a bit overwhelmed by the many requests that arrive each week, so please forgive me, if I fail to respond personally. I am still very likely to at least skim read your request and I'll probably try to fix all (real) bugs if possible and I will likely review every single PR being made (please, give me a heads up if you intent to do so) and I will try to work on popular requests (please upvote via thumbs up on the original issue) whenever possible, but trying to respond to every single issue over the last years has been kind of draining and I need to adjust my approach for this project to remain fun for me and to make any progress with actually coding new stuff. Thanks for your understanding!

[Blackclaws]

You need to either put a group path at the top and select: "Group" as source

Or you need to put a project path and select "Project" as source.

Both work fine for me even for subgroups.

You need to paste the full group/project path too, so if you have a company group called:

CompanyA

with a subgroup Teams you need to put

CompanyA/Teams/BackendTeam

Let me know if you have further issues.

Edit: It might be that subgroup sources don't work correctly after all, I apparently was trying with project in subgroup which works fine. Standard group sources and project sources work fine though.

[Nezteb]

Attempting this again:

Subgroup

• I have a group/team in GitLab: https://gitlab.com/company/backend-team
• I enter company/backend-team into the text box
• I set the "Source" to "Group", save, wait for the app to pull issues, and the app calls:
  • https://gitlab.com/api/v4/projects/company%2Fbackend-team/issues
  • This 404s
• I set the "Source" to "All", save, wait for the app to pull issues, and the app still calls the same URL and 404s

Top-level group

• I enter just company into the text box
• The app now calls:
  • https://gitlab.com/api/v4/projects/company/issues
• The call still 404s
  • I tried with both "Group" and "All" for the "Source" dropdown, same result

Project

If I repeat all of these same but for a specific repo, say https://gitlab.com/company/mobile-app, everything works, because it's using the /projects endpoint.

Summary

So, I think pulling issues for an entire group is broken. There is code for handling groups, but it doesn't seem to be working:

super-productivity/src/app/features/issue/providers/gitlab/gitlab-api/gitlab-api.service.ts

Lines 397 to 401 in 9efed16

	if (project || projectConfig.source === 'project') {
	apiURL += 'projects/' + projectURL;
	} else if (projectConfig.source === 'group') {
	apiURL += 'groups/' + projectURL;
	}

[github-actions]

This issue has not received any updates in 90 days. Please comment, if this still relevant!

[excalios]

This issue is still relevant when getting notes or the issue detail itself is still giving an error. I would love it if anyone could help with this issue or give hints. Personally, this is very disturbing. Since, sometimes not all of my issue is loaded and even if it does it always shows an error popup.

When trying to get issues by its iids it will be an error since it will hit projects/{PROJECT} meanwhile {PROJECT} is set based on group or even username when set into GROUP or ALL. When getting issue details it has the same behavior.

I'm currently trying to understand the codebase and the GitLab API itself. So far what I got is:

Getting by iids

GROUP

When getting by iids it should still hit the groups endpoint but it currently hits the projects endpoint since we passed projects arguments from the GitLab config. Which is the group name, not the project name. I tried to fix it by changing the _apiLink function inside gitlab_api.service.ts specifically this part:

    if (
      (project !== projectConfig.project && projectConfig.project !== 'group') ||
      projectConfig.source === 'project'
    ) {
      apiURL += 'projects/' + projectURL;
    } else if (projectConfig.source === 'group') {
      apiURL += 'groups/' + projectURL;
    }

I checked whether the project that is passed is the same as the config and if it's not group it goes to group. Changing it into a switch and handling it inside switch case might be better.

ALL

I haven't checked this but with the fix above it will try to hit projects with our username that is set

Get issue detail

The issue is the same as it doesn't hit the proper projects, I tried to get from single issues endpoint but it's administrator only. I'm thinking it should pass the proper project id so the getProject function can return the project id for that specific issue. But, I haven't been able to find the specific part of the code that handles this logic.

[excalios]

is it possible to open this issue since it's still relevant? @johannesjo

[kronehero]

In version 10.0.11 on Windows 11, I can successfully access the issues for all group projects using the GitLab integration. I still can't use it because on the second automatic pull all issues are added again, so I get duplicates of issues I already have in my list. This doesn't happen if I use "Project" as source instead of "Group" in the integration settings.

In my eyes this problem is part of the GitHub issue and I just want to mention it here. Please let me know if it's not a problem at all and can be fixed by changing the configuration.

This is what my GitLab integration setup looks like:

[cbergmann]

Hi, after some month I tried the gitlab integration again. I found out that currently the "source" option is no longer available. I still have the requirement to search for issues on a group or instance level. Adding multiple Providers is not a option because there are many projects and they also change often.

I therefore propose the following change:

1. add a new Option for the gitlab issue provider "search scope" which has the options "project", "group", "instance".
2. The default for existing and new configurations is "project". This does not change the current function.
3. Depending on the selected option the search requests use the "/projects/:id/issues", "/groups/:id/issues" or "/issues" endpoint respectively.
4. For the ':id' in the "/groups/:id/issues" endpoint the "user name/project" config option is split by "/" and all but the last parts are used as ':id'.
5. Create and update requests always use the respective "/projects/:id/issues" endpoints.

I will look into this in the next days and see if I can create a small merge request. Any hints or improvements on this proposal are welcome. I have not looked into the datamodel if we need to change it to save the project of the issues to make the requests for "/projects/:id/issues/:id" etc. possible in this scheme as we could have issues from multiple project when searching for "group" or "instance" issues. Tips on this are also very welcome.

Kind regards
Clemens

[cbergmann]

Hi, this would be my proposal for the instance/group issue search feature: !3901

While testing I found that the submission of spent time seems to not be working also. I might look into this if I could find time.