Bug 1442087

Summary:	REST API for service_requests/:id/tasks returning Tasks not seemingly associated with the defined service_task
Product:	Red Hat CloudForms Management Engine	Reporter:	Ryan Spagnola <rspagnol>
Component:	API	Assignee:	Jillian Tullo <jtullo>
Status:	CLOSED ERRATA	QA Contact:	Martin Kourim <mkourim>
Severity:	medium	Docs Contact:
Priority:	high
Version:	5.7.0	CC:	gtanzill, jhardy, jtullo, myoder, obarenbo, rspagnol, simaishi
Target Milestone:	GA	Keywords:	Reopened
Target Release:	5.9.0
Hardware:	All
OS:	All
Whiteboard:	service:api
Fixed In Version:	5.9.0.1	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-03-01 13:11:36 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:

Comment 2 Jillian Tullo 2017-04-18 19:23:35 UTC

Hi Ryan-

I looked into this issue and was unable to recreate it. The tasks returned are the tasks that are associated to the service_request that was requested.

Is there any additional information you can provide such as the dates that seemed incorrect? There are a couple of dates here (service request date, task updated/created at/delivered on date) that could be of help.

Thank you

Comment 4 Jillian Tullo 2017-04-24 18:48:41 UTC

Hi Ryan-

I tested Euwe as well as master. Is it possible to get more information about the timestamps?

Thanks!

Comment 6 Jillian Tullo 2017-05-01 18:44:32 UTC

Hey Yoder,

After taking a look at your appliance, I do not see any irrelevant tasks. I have also looked closely at the API code and ran some separate tests to ensure that the correct tasks are being returned, and I have not been able to reproduce any problems.

Happy to take a look if you think you encounter this again - screenshots and exact tasks would be helpful for debugging.

Thanks!
- Jillian

Comment 9 Jillian Tullo 2017-05-25 19:55:01 UTC

Hi Ryan,

Apologies for the delay. Yes, please put something on my calendar so that we can go through the issue together.

Thanks!
- Jillian

Comment 11 Jillian Tullo 2017-05-30 14:16:42 UTC

Hi Ryan--

was it possible to get the JSON response of the actual tasks? In particular, 

https://cfme.test.kent.edu/api/service_requests/1000000000174/tasks?expand=resources

and 

https://cfme.test.kent.edu/api/service_requests/1000000000174/request_tasks?expand=resources

Thanks!

Comment 12 Jillian Tullo 2017-05-31 19:05:07 UTC

Hi Ryan--

I no longer need that information as I found the root cause of the problem.

Here is a PR that explains the issue:
https://github.com/ManageIQ/manageiq/pull/15265

Essentially, `/request_tasks` is the API call that should be made and the `/tasks` request should be avoided.

What is happening is the `/tasks` is pretty much configured incorrectly, so when you get the hrefs back, they are referencing a different object than the actual tasks that are associated with the service requests.

Thanks!!

Comment 13 Jillian Tullo 2017-06-13 14:02:27 UTC

Updated PR: https://github.com/ManageIQ/manageiq/pull/15357

Comment 14 Martin Kourim 2017-12-07 17:52:59 UTC

Verified that "request_tasks" is returned instead of "tasks" and that "tasks" is redirected to "request_tasks" when "tasks" subcollection is accessed.

GET /api/service_requests/1/tasks/1
{
    "href": "https://<addr>/api/service_requests/1/request_tasks/1",
    ...

GET /api/service_requests/1/tasks
{
    "name": "request_tasks",
    ...
    "resources": [
        {
            "href": "https://<addr>/api/service_requests/1/request_tasks/1"
        }
    ...

Comment 17 errata-xmlrpc 2018-03-01 13:11:36 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, 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