Closed Bug 622487 Opened 13 years ago Closed 13 years ago
Product and component mismatch , a product without any component gets component of other projects in advance search
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20100216 Fedora/3.5.8-1.fc11 Firefox/3.5.8 Build Identifier: 4.0rc1 We have already few products in bugzilla, each with its own component list. Recently we create 3 products in bugzilla two of them without any component. These new products are placed in between the existing product line up and not at the end (the way it is shown in advance search product listing). When we select a product from product in drop down box , there corresponding components are populated in components drop down. But as two products dont have any components they should have been empty. Instead these product shows components from other products. The cpts and vers array created for each product is not creating an empty array when a product dont have any component. When the product drop down shows 10 products the cpts and vers array size should be 10 and not less. Reproducible: Always Steps to Reproduce: 1. Create product a b c with sub compoents a1 b1 and c1 2. check the advance search that when you click a you get a1 and when you click b gets b1 in component 3. Create a product aa without any components 4. Now check the advance search product a should show a1 as component but product aa shows b1 as its component and prodct b shows c1 as component and product c shows no component. Actual Results: Product component Mismatching Expected Results: There should not been any mismatch between product and component association. cpts and vers array population need to handle products with no compoents.
We probably won't fix this, since products with no components can't be used for anything in any part of Bugzilla.
Priority: -- → P5
Well, I'm rather surprised these products are listed in the search form. Products without components are excluded by get_enterable_products(), but not by get_selectable_products() which is used in query.cgi. We should fix it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Priority: P5 → P4
Hardware: x86 → All
Version: unspecified → 4.0
Here is a workaround for query.cgi. Initially, I wanted to fix get_selectable_products() to exclude products with no components (thanks to INNER JOIN components), but the problem is that this method is called by some admin methods (such as Bugzilla::Version->create and Bugzilla::Miletone->create) and so these methods were throwing an error, complaining that the admin wasn't allowed to see this new product. So ideally, we would need check_can_admin_product() not call can_see_product(), but run its own query, without "INNER JOIN components". To avoid code duplication, this would mean some refactoring in User.pm. Not sure it worths the effort, though.
Also, note that this fix isn't needed in 4.1. It's working fine there.
(In reply to comment #5) > Also, note that this fix isn't needed in 4.1. It's working fine there. I take that back. This was working fine because I had classifications enabled. Else the problem is still present.
I have 10 Product and i did not have a component for the 2nd Product, Once i created a component this is working fine now. Chirag
I also discovered this bug. Please consider bug 674542 to avoid this. I would prefer if checksetup.pl reports a warning/error if there are products without components. (as it makes no sense)
sorry I meant sanitycheck.pl of course s/checksetup.pl/sanitycheck.pl
The ultimate solution here is to always create a default component called "General" (l10n-able) when creating a product and have it have the product creator as the default assignee.
In bug 661476, I changed the "create a new product" UI to also let the admin create a component at the same time.
(In reply to comment #15) > In bug 661476, I changed the "create a new product" UI to also let the admin > create a component at the same time. Okay. I'll respond over there.
Comment on attachment 514560 [details] [diff] [review] workaround This workaround is enough. No need to hack the code even more for something which doesn't happen so often, and which is now caught by sanitycheck.cgi.
Attachment #514560 - Flags: review?(mkanat)
Comment on attachment 514560 [details] [diff] [review] workaround Honestly, I don't even want to do this. I feel like agreeing to do this would also mean agreeing to do it everywhere else that it might cause a problem in the future, and I don't want to commit to that. I think the sanitycheck check is enough--my viewpoint is that if sanitycheck is failing, you can't expect Bugzilla to behave properly.
Attachment #514560 - Flags: review?(mkanat) → review-
I would agree to put the workaround into the branches where the sanitycheck isn't going, though.
(In reply to Max Kanat-Alexander from comment #19) > I would agree to put the workaround into the branches where the > sanitycheck isn't going, though. That's what I was going to suggest. :)
Comment on attachment 514560 [details] [diff] [review] workaround Okay. r+ only for those branches, then. :-)
Attachment #514560 - Flags: review- → review+
OK, I will commit this patch for 4.0.3 and 4.2rc1 only. This patch is not needed for 5.0 thanks to bug 661476.
Assignee: query-and-buglist → LpSolit
Status: NEW → ASSIGNED
Target Milestone: --- → Bugzilla 4.0
Committing to: bzr+ssh://email@example.com/bugzilla/4.2/ modified query.cgi Committed revision 7912. Committing to: bzr+ssh://firstname.lastname@example.org/bugzilla/4.0/ modified query.cgi Committed revision 7646.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.