4

I am trying to track a GitLab issue no matter in what project it may reside.

An issue is normally created in GitLab within the context of a project. If it is moved to another project, the issue is closed and a new issue is created. The original issue tracks the new location using the moved_to_id. The problem is I have no idea how to follow this moved_to_id value using the GitLab API v4. GitLab does not honour the typical REST-like behaviour where you can retrieve an entity by its ID.

For example, if I call https://gitlab.com/api/v4/issues/ I'll get a list of issues as objects: these objects have a set of fields: title, description, state, ..., id and iid. The iid is the user-friendly id of an issue within a project. But what is the id and how is it useful? I can't retrieve an issue using this id - at least not using expected ways...

Consider an issue exists in https://gitlab.com/api/v4/issues/ with id == 29564819,

  1. https://gitlab.com/api/v4/issues/29564819 returns a 404.
  2. https://gitlab.com/api/v4/issues/29564819/ returns a 404.
  3. https://gitlab.com/api/v4/issues/29564819?scope=all returns a 404
  4. https://gitlab.com/api/v4/issues/?id=29564819 returns all the issues (no effect using parameter).

Can I retrieve an issue without a project? Do I have to resort to using labels?

Cheez
  • 41
  • 2
  • I'm having a similar problem, I need to list all issues with given `id`s, but there's only `iids[]` parameter, I wonder who designed these APIs... Did you find a solution for your problem? – José Pedro Oct 10 '21 at 18:18
  • 1
    I gave up, to be honest. I was hoping the Internet geniuses or a subject matter expert from GitLab would swoop down and provide an answer :) – Cheez Oct 11 '21 at 19:48
  • ok, I see, thanks anyway! – José Pedro Oct 13 '21 at 14:28

2 Answers2

0

If a user is not a member of a private project, a GET request on that project results in a 404 status code.

Only administrators can retrieve issue by its id.

The preferred way to do this is by using personal access tokens.

GET /issues/:id

Binoy Nixon
  • 1
  • 3
0

I believe the possible reason is that the API endpoint you mentioned earlier might be restricted to administrators only, as stated in the documentation for Single Issue). In other words, it is suitable for self-hosted GitLab instances.

If that's not the case, you should consider using a slightly different endpoint, Single Project Issue, specifying the appropriate project ID and issue IID (not an ID).

Gleb
  • 121
  • 1
  • 4