Bug #32704

The /api/usergroups/:usergroup_id/external_usergroups API is not accepting 1-group as the name of usergroup

Added by Tomer Brisker over 1 year ago. Updated over 1 year ago.

Users, Roles and Permissions
Target version:
Bugzilla link:
Fixed in Releases:
Found in Releases:
Red Hat JIRA:


Cloned from

Description of problem:

The redhat.satellite.external_usergroup calls this API --> GET /api/usergroups/:usergroup_id/external_usergroups

As per the satellite apidoc the :usergroup_id , should be a string

But if I decide to use a satellite usergroup name e.g "1-group" , it fails whereas "1 group" works fine.

So the hyphen (-) is creating some sort of issue here.

Version-Release number of selected component (if applicable):

Satellite 6.9

How reproducible:


Steps to Reproduce:
1. Build a Satellite 6.9

2. Create a usergroup by name "1-group"

3. Run following API --> curl -ku admin:RedHat1! ""

4. Modify the usergroup name from "1-group" to "1 group"

5. Run following API --> curl -ku admin:RedHat1! ""

Actual results:

Step 3 error:
~~ {
"error": {"message":"Resource external_usergroup not found by id ''"}


Step 5 success:
~~ {
"total": 0,
"subtotal": 0,
"page": 1,
"per_page": 20,
"search": null,
"sort": {
"by": null,
"order": null
"results": []

Expected results:

Step 3 should be successful as well.

Additional info:

This affects the working of redhat.satellite.external_usergroup module if customer decided to map an AD group to Satellite usergroup by name "043-enterprise systems"

Related issues

Related to Foreman - Refactor #23234: remove friendly_id <5.0 workaroundsClosed

Associated revisions

Revision 3d3efb62 (diff)
Added by Tomer Brisker over 1 year ago

Fixes #32704 - Improve parent scope identification

When a parent resource has a name that appears like it is
parameterized but actually isn't (such as `1-name`), we try to find
the parent scope from the resource name but fail (since the actual id of
the record is different).
Instead of attempting to handle parameterized strings first, we try
finding by friendly id first when it makes sense, and fallback to
handling parameterized strings only if no matches are found with
friendly id.


#1 Updated by Tomer Brisker over 1 year ago

  • Category set to Users, Roles and Permissions

The issue comes from which tries to run `from_param` on the usergroup name, which is not correct in this case (friendly id should be used instead)

#2 Updated by Tomer Brisker over 1 year ago

looking at the specific request again, looks like it's actually that is the culprit where finding the nested object does not work as expected

#3 Updated by Tomer Brisker over 1 year ago

#4 Updated by The Foreman Bot over 1 year ago

  • Assignee set to Tomer Brisker
  • Status changed from New to Ready For Testing
  • Pull request added

#5 Updated by The Foreman Bot over 1 year ago

  • Fixed in Releases 3.0.0 added

#6 Updated by Tomer Brisker over 1 year ago

  • Status changed from Ready For Testing to Closed

Also available in: Atom PDF