Description of the problem, including code/CLI snippet

objects.epics.GroupEpic uses iid (group local ID) as ID attribute / encoded_id instead of the global id like, for example, objects.issues.ProjectIssue does. This leads to an erroneous behavior when updating an epic, i.e., the wrong epic is being updated.

Expected Behavior

• I retrieve an epic: epic = top_level_group.epics.list(...)[0]
• I manipulate the epic labels: epic.labels.extend([...]) <-- epic from a sub group
• I save the epic: epic.save()
• The new labels are saved for exactly this epic, identified by epic.id.

Actual Behavior

• The labels are saved for the first epic with epic.iid, which is not necessarily the one that I intended to update.

Discussion

The class GroupEpic explicitly sets iid as _id_attr. When updating the epic, the request is sent to epic.manager.path/{epic_iid}, but since epic.manager.path is the path to the top level group, the epic with id 3 in this top level group is updated instead of the one from the nested group.

So maybe it's not just using id instead of iid but fixing the manager (path) so that is uses the path of the actual group that the epic belongs to and not the path of the group that was used to retrieve all epics.

Specifications

• python-gitlab version: 6.20 (but has been around since months or years and does still exist: https://github.com/python-gitlab/python-gitlab/blob/main/gitlab/v4/objects/epics.py#L26)
• Gitlab server version (or gitlab.com): recent / not important