Bug 1298497

Summary: 404 error for content view filter update procedure
Product: Red Hat Satellite Reporter: Oleksandr Shtaier <oshtaier>
Component: APIAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DEFERRED QA Contact: Katello QA List <katello-qa-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.1.6CC: bkearney
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-23 20:21:07 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 Oleksandr Shtaier 2016-01-14 09:41:11 UTC
Description of problem:
Trying to update content view information (content view id) for existing content view filter entity and constantly getting 404 error.

For example:

PUT: https://your_server/katello/api/v2/content_view_filters/16
     {"content_view_id":100}

Error:
Received HTTP 404 response: {"displayMessage":"Couldn't find ContentViewFilter with id=16","errors":["Couldn't find ContentViewFilter with id=16"]}

Everything works fine in case I will try to update another field (e.g. 'type')

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

How reproducible:
Always

Steps to Reproduce:
1. Create couple of content view entries
2. Create content view filter for one content view
3. Try to update content view filter and assign another content view for it

Actual results:
404 error is raised

Expected results:
Update procedure passed successfully
or
In case that scenario is wrong due any reasons corresponding documentation entries for API should be changed and proper error message should be generated and displayed

Additional info:

Comment 1 Bryan Kearney 2016-07-26 19:06:49 UTC
Moving 6.2 bugs out to sat-backlog.

Comment 4 Bryan Kearney 2017-03-23 20:21:07 UTC
I do not believe this will be addressed in the next few releases, so I am closing this out. If you feel this was incorrect, please feel free to re-open with additional information.