Bug 782518

Summary: Search history - not working properly
Product: Red Hat Satellite Reporter: Brad Buckingham <bbuckingham>
Component: WebUIAssignee: Brad Buckingham <bbuckingham>
Status: CLOSED CURRENTRELEASE QA Contact: Katello QA List <katello-qa-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.0.1CC: mmccune
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-22 18:20:29 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 747354    
Attachments:
Description Flags
search favorites none

Description Brad Buckingham 2012-01-17 15:53:05 UTC
Description of problem:

When a user performs a search, the search request is stored in the user's search history to enable them to reuse it in the future by selecting the 'arrow' to the left of the search box and clicking on previous search from the list.  After the recent move to elastic search, it appears that the search history is no longer available to the user.  

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

How reproducible:
always

Steps to Reproduce:
1. go to Organizations
2. enter a search (e.g. name:ACME*)
3. wait for the search to be completed
4. click the arrow to the left of the search box (i.e. fancyquery)
  
Actual results:
User sees the 'Save as favorite' and 'Clear the search' options; however, they do not see the search just performed.

Note: the search is being stored in the DB.  E.g.

katelloschema=> select * from search_histories;
 id |   params   |             path             | user_id |         created_at  
       |         updated_at         
----+------------+------------------------------+---------+---------------------
-------+----------------------------
  1 | name:foo   | /katello/organizations/items |       1 | 2012-01-17 15:20:24.
428534 | 2012-01-17 15:20:24.428534
  2 | name:ACME* | /katello/organizations/items |       1 | 2012-01-17 15:20:36.
916728 | 2012-01-17 15:20:36.916728
(2 rows)


Expected results:
User should see the N (5) most recent searches in the dropdown and be able to click on them to perform the search again.

Additional info:

Comment 1 Brad Buckingham 2012-01-17 15:54:21 UTC
Created attachment 555819 [details]
search favorites

Comment 2 Mike McCune 2012-01-19 22:37:18 UTC
if this is overly difficult we can consider removing search favs

Comment 3 Brad Buckingham 2012-01-20 19:54:13 UTC
commit: b050ed7153a9d382c5fbf4e9f6eae758dd8270fb

It appears that this issue was addressed for most pages; however, the providers
page still had an issue with properly storing/accessing search history.

The issue with that page is that accessing the page was via a resource like:
/katello/organizations/:id/providers
however, the searches and history were performed over a resource like:
/katello/providers/...

The providers page is the only one that used the resource including organization; therefore, removed it to make it consistent and allow search history to work like the rest.

Comment 4 Mike McCune 2012-01-26 19:07:55 UTC
mass ON_QA move

Comment 6 Jeff Weiss 2012-02-10 20:29:23 UTC
Still does not work in katello-0.1.231-1.git.1.4ca672f.el6.noarch

Comment 7 Brad Buckingham 2012-02-13 20:24:46 UTC
commit - e442cb8da5682aa36b11422536113e268b424f0e

After comparing the development environment (where history works) and the production environment (where it does not), found that they issue is related to the HTTP_HOST received in the incoming request for search history.  This host is important as it is used by Katello to parse out the path (e.g. /katello/organizations) for the page the user is requesting history for.  

In the production environment, the host (e.g. https://127.0.0.1:5007/) does not match the value from the referer (e.g. https://katello.mycompany.com/).  This is likely due to the apache front-end proxying of the requests to the katello thin app instances.

In order to address this, converted the implementation to no longer rely on HTTP_HOST and instead leverage classes provided by the programming language to perform URI parsing to retrieve the path (e.g. /katello/organziations).

Comment 8 Jeff Weiss 2012-02-27 14:52:44 UTC
Verified, 0.2.3-1.git.0.941213c.el6

Comment 10 Mike McCune 2013-08-16 18:14:55 UTC
getting rid of 6.0.0 version since that doesn't exist