+++ 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):
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
No results for new packages pushed into channels after the upgrade to spacewalk-search-2.0.2-3
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 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>.
- 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.
--- 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.
Visibility queries updated to include shared channels (both 'public' and 'protected' shared channels).
Committing to Spacewalk master:
*** Bug 1109246 has been marked as a duplicate of this bug. ***
Moving bugs to ON_QA as we move to release Spacewalk 2.3
Spacewalk 2.3 has been released. See