Bug 1967319

Summary: The /api/usergroups/:usergroup_id/external_usergroups API is not accepting 1-group as the name of usergroup
Product: Red Hat Satellite Reporter: Sayan Das <saydas>
Component: Users & RolesAssignee: Tomer Brisker <tbrisker>
Status: CLOSED ERRATA QA Contact: sganar
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.9.0CC: apatel, egolov, mhulan, oezr, pcreech, sganar, tbrisker
Target Milestone: 6.11.0Keywords: Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-07-05 14:28:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sayan Das 2021-06-02 20:59:49 UTC
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:

Always


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! "https://satellite.example.com/api/v2/usergroups/1-group/external_usergroups/" 

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

5. Run following API --> curl -ku admin:RedHat1! "https://satellite.example.com/api/v2/usergroups/1%20group/external_usergroups/" 


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"

Comment 2 Tomer Brisker 2021-06-03 09:11:27 UTC
Created redmine issue https://projects.theforeman.org/issues/32704 from this bug

Comment 3 Tomer Brisker 2021-06-06 16:10:47 UTC
A workaround until this is fixed properly is to use the usergroup ID instead of its name in the api call, e.g. (assuming for example that the usergroups has id 5) `/api/usergroups/5/external_usergroups` or `/api/usergroups/5-043-enterprise systems/external_usergroups` instead of `/api/usergroups/043-enterprise systems/external_usergroups`. The root cause is that one of the functions incorrectly assumes that the number at the start of the usergroup name indicates its ID and tries (and fails) to find a usergroup with that ID.

Comment 4 Bryan Kearney 2021-06-06 20:04:59 UTC
Upstream bug assigned to tbrisker

Comment 5 Bryan Kearney 2021-06-06 20:05:01 UTC
Upstream bug assigned to tbrisker

Comment 6 Bryan Kearney 2021-06-08 16:05:20 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/32704 has been resolved.

Comment 11 errata-xmlrpc 2022-07-05 14:28:57 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: Satellite 6.11 Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:5498