Repository navigation
Group import fails when parent_id is passed as int #2506
Description
Description of the problem, including code/CLI snippet
Testing group export/import between different Gitlab instances. Used to the path of the group working as the group id, I tried the following:
gl.groups.import_group(buffer, path='group_slug', name='Group name', parent_id='path/to/parent')which yields
gitlab.exceptions.GitlabImportError: 400: parent_id is invalid
Not very descriptive but reading gitlab's api docs I find out:
parent_id, integer: ID of a parent group to import the group into. Defaults to the current user’s namespace if not provided.
So I try the numerical id of the group:
gl.groups.import_group(buffer, path='group_slug', name='Group name', parent_id=42)even worse:
AttributeError: 'int' object has no attribute 'encode'
Expected Behavior
Because the path works as an id in several calls (e.g. groups.get) I think the first version should work. The second version should definitely work.
Actual Behavior
In the end, after digging a bit on the code, what works is:
gl.groups.import_group(buffer, path='group_slug', name='Group name', parent_id='42')Specifications
- python-gitlab version: 3.13.0
- API version you are using (v3/v4): v4
- Gitlab server version (or gitlab.com): 15.8.1-ee
Activity
nejch commentedon Mar 4, 2023
Thanks for the report @vlizanae.
Regarding the confusing naming, this is really GitLab's behavior so i think we will want to keep it as is (we're just passing this to the API, so it's up to GitLab to accept IDs or url-encoded paths).
For your proposal to work, we would have to add another GET call inside the method, to find out the group's ID from the path, but as a library we really want to just be a thin wrapper around existing endpoints. If you want this behavior I'd write a little wrapper function to do so. Does that work for yo.u?
From experience, when
<something>_idis passed as a parameter, it usually is only the ID, whereas as part of the URL itself it usually accepts both. As we state in the docs (https://python-gitlab.readthedocs.io/en/stable/api-usage.html), we encourage users to check upstream docs for attribute specifics, it would be too much work for us to try and mirror the upstream docs here reliably.But the integer encoding issue is definitely a bug, we'll have to fix that, thanks again for the catch!
[-]Group import unintuitive parent_id format[/-][+]Group import fails when parent_id is passed as int[/+]vlizanae commentedon Mar 4, 2023
Hmm I didn't realize that passing the path as id was part of gitlab's API, I thought it was a feature of the library. I agree with just replicating the behavior of the API so it's ok having just the numerical id.
nejch commentedon Mar 4, 2023
I thought I'd propose a fix upstream in requests-toolbelt but they seem to deliberately not coerce to strings: requests/toolbelt#99.
So will need to be done on our side.
fix: support int for `parent_id` in `import_group`
fix: support int for `parent_id` in `import_group`
fix: support int for `parent_id` in `import_group`
fix: support int for `parent_id` in `import_group`
fix: support int for `parent_id` in `import_group`
fix: support int for `parent_id` in `import_group`