Api/user_groups/add_user behaviour


After the migration to 10.4, I found out a different behaviour on the now-deprecated api/user_groups/add_user API endpoint.

In 10.3, adding twice an user in a group was possible without an error occurring. The second time the process runs, nothing happens.
In 10.4, adding twice an user in a group results in an error:

User \u0027username\u0027 is already a member of group \u0027groupname\u0027"

This unfortunately breaks the itempotence of the tools we are using to provision user permissions :frowning:

Plus, it seems that the api/user_groups/add_user endpoint was deprecated in favour of /api/v2/authorizations/group-memberships, which is not yet documented.

EDIT: the V2 documentation is available now. This solves one issue :wink:

Is this a wanted behaviour ?


Hello @Mikaciu,

Thank you for your report.
During migration to v2 endpoints, we streamlined the code for the old endpoints and new ones where it makes sense. As a side-effect v1 endpoints indeed could cease to be idempotent, because it is assumed that all new POST requests will work that way.

Unfortunately, since it does not affect the logic of “happy path” for such endpoints and to avoid such situations we would need to add more complexity to the codebase we do not plan to fix this behavior for now.

Thank you,

Hello Viktor,

Thanks for the explanation !

In this case, would it be possible to have a changelog on what changed in the API endpoints (maybe a kind of release notes stating what has changed in the API between two versions of SonarQube) ? Or would this kind of link do the trick ?

We rely heavily on API to preconfigure projects (fine permissions, automatic application creation aggregating several projects, …) and this would allow us to test and modify our CLI before we schedule the new SQ delivery :wink:


Hello @Mikaciu,

We did not intend to change the behavior of v1 endpoints when migrating to v2 and before your report, we did not even know that it was affected in any way. Thanks to your case we will pay more attention to such unexpected changes in the future and if we notice one we will include information about that in the changelog of the endpoint itself and put a note in the release notes if we consider it potentially breaking for any automation on the user’s side.

However, there is still a risk that in some specific cases (meaning that we do not test and do not take into account such cases, like adding the same user in the same group twice in a row) we may implement some changes in the behavior that we would not be able to foresee. I hope that now that we know of such a case we will significantly reduce the possibility of implementing an unintended change, but can not guarantee their complete absence.

Thank you,

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.