Description of problem: When service is ordered from service catalog using the request on the service_templates subcollection, the data returned in response corresponds to the service_requests collection. However since no "href" is returned, it's hard to figure out that the response doesn't correspond to the originating subcollection (i.e. service_templates). When the request is made on a resource under the service_templates subcollection, the correct "href" is returned. Version-Release number of selected component (if applicable): 5.8.1.5 How reproducible: very Steps to Reproduce: Order catalog item from the service_templates subcollection: POST /api/service_catalogs/62/service_templates { "action": "order", "resources": [{ "href": "https://<address>/api/service_catalogs/:catalog_id/service_templates/:template_id" }] } Response: { "results": [ { "id": 27, "description": "Provisioning Service [item_4D2Nq] from [item_4D2Nq]", ... <= no "href" is present - it should point to "https://<address>/api/service_requests/27", otherwise it's difficult to find out what resource does the id belongs to. Compared to: POST /api/service_catalogs/62/service_templates/:template_id { "action": "order" } Response: { "href": "https://<address>/api/service_requests/28", "id": 28, "description": "Provisioning Service [item_4D2Nq] from [item_4D2Nq]", ... <= here the "href" is present
https://github.com/ManageIQ/manageiq-api/pull/104
Verified that href is returned when ordering service from the service_templates subcollection.
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, 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-2018:0380