You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Cannot update/patch protected branch allowed_to_push/push_access_levels state #2850
The Save and Update mixins for protectedbranch doesn't really work for most of it's attributes, as the PATCH/POST api use different values from those return by the API.
To be able to update the `allowed_to_push' GitLab protected branch state.
Actual Behavior
Using the python-gitlab library to modify the push_access_levels attribute that the object has and then calling .save() appears to do nothing, and the python object has no allowed_to_push attribute to modify.
It does work for the basic .allow_force_push protectedbranch attribute, as added and tested in the original Pull Request.
I think historically we have left issues like this up to the user to handle. As I think the idea of python-gitlab is to be a thin wrapper over the GitLab API. The positive to doing this is it makes things easier for the users. The negative is that it adds more work for the volunteer developers of python-gitlab to add this and there are other inconsistencies in the upstream API that would thus wanted to be added. And then the maintenance of this if GitLab changes the API.
This might be a good thing to raise upstream and ask GitLab to resolve this inconsistency.
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
The only work around I can think to allow modifying branch permissions is for the user to GET protectedBranch, implement their own translation code from push_access_levels structure to the allowed_to_push and then POST that.
The only work around I can think to allow modifying branch permissions is for the user to GET protectedBranch, implement their own translation code from push_access_levels structure to the allowed_to_push and then POST that.
@nickbroon this is what I do, yes, I call an update() on the manager itself, when encountering this.
I'm honestly just afraid we'd deviate from upstream parameters if we were making aliases/mappings between GET and PUT/POST/PATCH endpoints, and then confuse users even more. You wouldn't really be updating push_access_levels if we added a mapping, for example.
I'm assuming we'd be doing this in a generic way and not for every possible endpoint, similar to how we have _create_attrs, _update_attrs etc, but as a dict for the mapping.
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
I don't have permissions to remove the 'stale' label. But feel free to add the 'wont-fix' label and close this; I understand the libraries design decision to not translate between non-symmetric GET and PUSH/PATCH rest API in save/update mixins.
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
I don't have permissions to remove the 'stale' label. But feel free to add the 'wont-fix' label and close this; I understand the libraries design decision to not translate between non-symmetric GET and PUSH/PATCH rest API in save/update mixins.
I don't have permissions to remove the 'stale' label. But feel free to add the 'wont-fix' label and close this; I understand the libraries design decision to not translate between non-symmetric GET and PUSH/PATCH rest API in save/update mixins.
Activity
JohnVillalovos commentedon May 1, 2024
I think historically we have left issues like this up to the user to handle. As I think the idea of python-gitlab is to be a thin wrapper over the GitLab API. The positive to doing this is it makes things easier for the users. The negative is that it adds more work for the volunteer developers of python-gitlab to add this and there are other inconsistencies in the upstream API that would thus wanted to be added. And then the maintenance of this if GitLab changes the API.
This might be a good thing to raise upstream and ask GitLab to resolve this inconsistency.
Interested to get @nejch opinion about this.
@nickbroon Off topic, I was in Edinburgh just two days ago 😄 But now back in the Portland, Oregon area.
github-actions commentedon Oct 12, 2024
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
nickbroon commentedon Oct 12, 2024
The only work around I can think to allow modifying branch permissions is for the user to GET
protectedBranch, implement their own translation code frompush_access_levelsstructure to theallowed_to_pushand then POST that.nejch commentedon Oct 14, 2024
@nickbroon this is what I do, yes, I call an
update()on the manager itself, when encountering this.I'm honestly just afraid we'd deviate from upstream parameters if we were making aliases/mappings between GET and PUT/POST/PATCH endpoints, and then confuse users even more. You wouldn't really be updating
push_access_levelsif we added a mapping, for example.I'm assuming we'd be doing this in a generic way and not for every possible endpoint, similar to how we have
_create_attrs,_update_attrsetc, but as a dict for the mapping.github-actions commentedon Dec 14, 2024
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
nickbroon commentedon Dec 14, 2024
I don't have permissions to remove the 'stale' label. But feel free to add the 'wont-fix' label and close this; I understand the libraries design decision to not translate between non-symmetric GET and PUSH/PATCH rest API in save/update mixins.
github-actions commentedon Feb 14, 2025
This issue was marked stale because it has been open 60 days with no activity. Please remove the stale label or comment on this issue. Otherwise, it will be closed in 15 days.
nickbroon commentedon Feb 14, 2025
I don't have permissions to remove the 'stale' label. But feel free to add the 'wont-fix' label and close this; I understand the libraries design decision to not translate between non-symmetric
GETandPUSH/PATCHrest API in save/update mixins.JohnVillalovos commentedon Feb 14, 2025
Thank you. Will do.