Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionBrad 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:
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.
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).
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: