Bug #19707: Searching for specific organizations/locations broken - Foreman

Custom queries

3.10.0 release DONE
3.10.0 release TODO
3.11.0 release DONE
3.11.0 release TODO
3.8.1 release DONE
3.8.1 release TODO
3.9.2 release DONE
3.9.2 release TODO
All bugs by votes
All issues closed in the last 3 weeks
Easy and Trivial Issues
Easy Issues (only)
Foreman - new open issues in last 10 days
Good first issues - Foreman core
high prio open bugs
Host registration [open]
Mine
My issues closed in the last 3 weeks
old bugs
Open with target version set (aka blockers)
registration
taken-none
Team Atlas untriaged bugs
templates
Trivial Issues
Untriaged and opened in the past two weeks

Actions

Copy link

Bug #19707

closed

Searching for specific organizations/locations broken

Added by Anonymous almost 7 years ago. Updated almost 6 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Ondřej Pražák

Category:

Organizations and Locations

Target version:

1.15.4

Difficulty:

Triaged:

Bugzilla link:

1472863

Pull request:

https://github.com/theforeman/foreman/pull/4815, https://github.com/theforeman/foreman/pull/4821

Fixed in Releases:

Found in Releases:

1.15.0

Red Hat JIRA:

Description

If I try to search through subnets with location_id every subnet is returned as long as the location_id actually exists. If I search for a nonexsitent location_id no subnet gets returned.
Also searching for organizations seems to be broken too, because when I enter a location name as organization I get a list of all subnets.

Examples:

Subnet1:
name: net1-mgmt
location_id: 8

Subnet2:
name: net2-mgmt
location_id: 9

search_string: location_id = 9 and name ~ net%-mgmt

Result: Both Subnets
Expected Result: Subnet2

search_string: location_id = 90 and name ~ net%-mgmt

Result: Nothing
Expected Result: Nothing (this is actually correct)

search_string: organization_id = 9 and name ~ net%-mgmt

Result: Both Subnets
Expected Result: Nothing as organization_id 9 does not exist

Files

proxies.png

View proxies.png

17.5 KB

Anonymous, 05/30/2017 12:40 PM

Related issues 2 (0 open — 2 closed)

	Related to Foreman - Bug #20867: Scoped search 4.1.1 introduces a regression and breaks tests	Closed	Marek Hulán	09/07/2017			Actions
	Related to Foreman - Bug #20872: Update scoped_search to 4.1.2 or higher	Closed	Daniel Lobato Garcia	09/07/2017			Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Anonymous almost 7 years ago

Somebody on IRC had the same problem with an API call for getting a list of proxies per location. This worked in 1.14: '/api/smart_proxies?search=feature=TFTP+and+location=xxx'

Actions

Copy link

Updated by Anonymous almost 7 years ago

Subject changed from Searching subnets for specific location_id to Searching for specific organizations/locations broken
Category changed from Search to Organizations and Locations

Actions

Copy link

Updated by Daniel Lobato Garcia almost 7 years ago

I'm currently not able to reproduce this neither the comment by mmoll, I'll try later with exactly the same setup as described in the issue.

Actions

Copy link

Updated by Anonymous almost 7 years ago

File proxies.png proxies.png added

See the attached picture for my proxies. geode.kvedulv.de is only in the location "Home", but still is showing up in the search results via API:

mmoll@sledge:/tmp$ http --verify=no --auth mmoll:xxx 'https://sledge.kvedulv.de/api/smart_proxies?search=location=GCSC2'
[...]
{
    "page": 1, 
    "per_page": 20, 
    "results": [
        {
            "created_at": "2017-02-25 21:35:42 UTC", 
            "features": [
                {
                    "id": 4, 
                    "name": "DHCP" 
                }, 
                {
                    "id": 16, 
                    "name": "Logs" 
                }
            ], 
            "id": 3, 
            "name": "geode.kvedulv.de", 
            "updated_at": "2017-02-25 21:35:42 UTC", 
            "url": "https://geode.kvedulv.de:8443" 
        }, 
        {
            "created_at": "2015-04-10 11:19:19 UTC", 
            "features": [
                {
                    "id": 6, 
                    "name": "Puppet CA" 
                }, 
                {
                    "id": 5, 
                    "name": "Puppet" 
                }, 
                {
                    "id": 14, 
                    "name": "Dynflow" 
                }, 
                {
                    "id": 15, 
                    "name": "SSH" 
                }, 
                {
                    "id": 16, 
                    "name": "Logs" 
                }, 
                {
                    "id": 2, 
                    "name": "TFTP" 
                }
            ], 
            "id": 1, 
            "name": "sledge.kvedulv.de", 
            "updated_at": "2016-09-14 18:25:54 UTC", 
            "url": "https://sledge.kvedulv.de:8443" 
        }
    ], 
    "search": "location=GCSC2", 
    "sort": {
        "by": null, 
        "order": null
    }, 
    "subtotal": 2, 
    "total": 2
}

Actions

Copy link

Updated by Marek Hulán almost 7 years ago

I can reproduce as well. It's not specific to API. I put some reproducing and debugging info here - https://gist.github.com/ares/6c5dc51581e20805b7798212960bc108

Actions

Copy link

Updated by Christian Schulze-Wiehenbrauk almost 7 years ago

Marek Hulán wrote:

I can reproduce as well. It's not specific to API. I put some reproducing and debugging info here - https://gist.github.com/ares/6c5dc51581e20805b7798212960bc108

I had a look at the sql statement and it seems that a filter is missing for the sub select: taxable_taxonomies.type = $1 resp. taxonomies.type = $2. This leads to a erroneous result set, containing ids that have the wrong taxable_taxonomies.type.

Actions

Copy link