Bug 1129827 - In spacewalk-search-2.0.2.-3, rhn-search package and errata visibilty queries not returning results for some users
Summary: In spacewalk-search-2.0.2.-3, rhn-search package and errata visibilty queries...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 2.2
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: Stephen Herr
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
: 1109246 (view as bug list)
Depends On: 1098402
Blocks: 1109260 space23
TreeView+ depends on / blocked
 
Reported: 2014-08-13 18:03 UTC by Stephen Herr
Modified: 2015-04-14 19:03 UTC (History)
7 users (show)

Fixed In Version: spacewalk-search-2.3.1-1
Doc Type: Bug Fix
Doc Text:
Clone Of: 1098402
Environment:
Last Closed: 2015-04-14 19:03:17 UTC


Attachments (Terms of Use)

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


Note You need to log in before you can comment on or make changes to this bug.