Bug 1129827

Summary: In spacewalk-search-2.0.2.-3, rhn-search package and errata visibilty queries not returning results for some users
Product: [Community] Spacewalk Reporter: Stephen Herr <sherr>
Component: ServerAssignee: Stephen Herr <sherr>
Status: CLOSED CURRENTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: high Docs Contact:
Priority: urgent    
Version: 2.2CC: cperry, dyordano, mhuth, mmraka, satqe-list, tlestach, xdmoon
Target Milestone: ---Keywords: Patch, Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spacewalk-search-2.3.1-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1098402 Environment:
Last Closed: 2015-04-14 19:03:17 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:
Bug Depends On: 1098402    
Bug Blocks: 1109260, 1207293    

Description Stephen Herr 2014-08-13 18:03:51 UTC
+++ This bug was initially created as a clone of Bug #1098402 +++

Description of problem:
After upgrading to spacewalk-search-2.0.2-3, rhn-search isn't returning the same results for certain users that is was before upgrading.  

The issue only presents with packages that have been introduced to the system since the upgrade to spacewalk-search-2.0.2-3.  This means that a search for 'kernel' will yield results just fine because there was already a package on the satellite called 'kernel' before the upgrade.  However doing a search for 'jiramail' doesn't work for some users though because the first version of that package was pushed after the upgrade.

It seems that changes to verifyPackageVisibility and verifyErrataVisibility queries in spacewalk-search-2.0.2-3 are causing the problems and the customer has confirmed that reverting these queries to what they were in 2.0.2-2 resolves the issue for them.

Version-Release number of selected component (if applicable):
spacewalk-search-2.0.2-3

How reproducible:
Always

Steps to Reproduce:
Not certain how to reproduce, but the customer has provided us with their DB on which we can reproduce the same behaviour.  On their DB:

0. Upgrade to spacewalk-search-2.0.2-3
1. Login to reproducer as <user>/<password> (they are org 3)
2. Search for jiramail or atlassian packages and get no results
3. Downgrade to spacewalk-search-2.0.2-2
4. Search again and this time results are returned for both packages

Actual results:
No results for new packages pushed into channels after the upgrade to spacewalk-search-2.0.2-3

Expected results:
Users should be able to get the same search results with 2.0.2-3 as they were getting on 2.0.2-2

Additional info:

--- Additional comment from Mark Huth on 2014-05-22 19:22:37 EDT ---

A good example of this problem, is to login as <user>, go to Channels -> Package Search and search for jiramail with a 'Where to search' of 'Specific channel you have access to' equal to 'rhel-6-server-adds'.  There are no results for jiramail.  However, you will find by navigating the UI, that the jiramail package is in the rhel-6-server-adds channel and <user> does have access to that channel.  Also, none of the other 'Where to search' functions find the package either (and even when selecting all arches in 'Packages of a specific architecture...') for <user>.

However if you revert to spacewalk-search-2.0.2-2, then all of these searches work for <user>.  

Other notes:
- The jiramail-1.3-1 package has id 137759.
- Its in channel rhel-6-server-adds which has id 192
- rhel-6-server-adds is in orgs 1 2 3 5 24 27
- The <user> user has id 127 and is in org 3

With the old verifyPackageVisibilty query the <user> user can see the jiramail-1.3-1 package via any of the package searches.  The <other_user> user is in org 1 and <other_user> is in org 24 - which is why they can see it too.

However with the new verifyPackageVisibility query, the <user> user is unable to see the jiramail package anymore with any of the searches (but <other_user> and <other_user> still can).

Note, there are other users/packages for which the search doesn't work either, but I have just selected <user> and jiramail for this example.

Hope that helps further define the problem.
Mark

--- Additional comment from Stephen Herr on 2014-05-23 09:45:15 EDT ---

Thanks for the extra info Mark.

This is a valid bug. The problem is that the visibility queries do not take into account channels that the user can see but where the user doesn't have access to that channel family. Specifically this is the case when one org (in this case org 1) has created a custom channel and then shared access of that channel with another org (<user>'s org, org 3). <user> will not have access to org 1's private channel family, but will have access to a channel in it.

Comment 1 Stephen Herr 2014-08-14 18:18:44 UTC
Visibility queries updated to include shared channels (both 'public' and 'protected' shared channels).

Committing to Spacewalk master:
4aa1e45c7a8e177222930dacb12f8997fd339b3e

Comment 2 Stephen Herr 2015-02-10 15:20:02 UTC
*** Bug 1109246 has been marked as a duplicate of this bug. ***

Comment 3 Grant Gainey 2015-03-23 16:59:08 UTC
Moving bugs to ON_QA as we move to release Spacewalk 2.3

Comment 4 Grant Gainey 2015-04-14 19:03:17 UTC
Spacewalk 2.3 has been released. See

https://fedorahosted.org/spacewalk/wiki/ReleaseNotes23