The API docs say Product.get_product() returns "A hash containing one item, 'products', that is an array of hashes. ..." But instead it's returning a hash containing many items where the key is the product name and the value is a list of info about that product. For example: product_ids = bz._proxy.Product.get_accessible_products() r = bz._proxy.Product.get_products(product_ids) print r['Beaker'] gives: [['command line', 'inventory', 'lab controller', 'scheduler', 'test harness', 'tests', 'Web UI Inventory'], ['0.4', '0.5'], ['---']] (I checked https://bugzilla.redhat.com/docs/en/html/api/Bugzilla/WebService/Product.html and http://www.bugzilla.org/docs/3.2/en/html/api/Bugzilla/WebService/Product.html for API details.)
Noura, can you look into this please?
Will is actually right, upstream bugzilla had Product.get returning a hash with a single item products that points to an array pf hashes, each hash with a product details "name, id, description, product object",, but we have actually customized the Product.get function in our redhat bugzilla to return a single hash for all products, its keys are the product names each key pointing to array of arrays of product components, versions, and milestones, we have done this customization so we can use Product.get in our Ajax rpc, I am going to fix the documentation to match with our customizations to the function, thanks for pointing that out Will, So will you be able to use Product.get as how we have it now? or do you need some other kind of information? Noura
Whoa. I'd strongly prefer that you keep the method matching the API as defined by upstream, and use a different name (perhaps in the rh-specific compat namespace) for the rh-specific method defined here.
(In reply to comment #3) > Whoa. I'd strongly prefer that you keep the method matching the API as defined > by upstream, and use a different name (perhaps in the rh-specific compat > namespace) for the rh-specific method defined here. I agree with Will that the 3.X XMLRPC API (i.e. Bugzilla/WebService/Product.pm) should stay consistent with the upstream format as much as we can. I don't mind us adding additional data to the returned value as long as the structure is intact. If Will's code is requiring the old format to continue to work properly, then we can create a new method in the compat_xmlrpc namespace and he can convert to use that. Whichever is less work on Will's side. As for our Ajax calls requiring the old format, we can easily convert them to use the new format in a code update. Dave
(In reply to comment #4) > (In reply to comment #3) > > Whoa. I'd strongly prefer that you keep the method matching the API as defined > > by upstream, and use a different name (perhaps in the rh-specific compat > > namespace) for the rh-specific method defined here. > > I agree with Will that the 3.X XMLRPC API (i.e. Bugzilla/WebService/Product.pm) > should stay consistent with the upstream format as much as we can. I don't mind > us adding additional data to the returned value as long as the structure is I would recommend that we keep the upstream API as is. No changes. Not Ever. If we needed to change the format or embellish the return structure then we should add a new routine. Adding a new routine is easy and maintainable and should make it obvious to the user that they are using a custom feature rather than upstream.
(In reply to comment #5) > I would recommend that we keep the upstream API as is. No changes. Not Ever. If > we needed to change the format or embellish the return structure then we should > add a new routine. Adding a new routine is easy and maintainable and should > make it obvious to the user that they are using a custom feature rather than > upstream. Definitely prefer this approach. And for the sanity of people using WebServices, can I gently suggest that modifications not accepted upstream might be better kept out of the upstream-defined Bugzilla namespaces? It'll get really confusing if *some* Bugzilla instances have Product.list_for_ajax() and some don't..
Note, there's an sereport failure ( #555975) due to _this_ bug, which has been filed at least 40 times now by abrt, and growing by the hour. Any chance this can be fixed soon? It's hitting everyone whose system runs sereport (the default) to report any selinux avc message. Please attempt to address this in bugzilla ASAP.
Hi Matt, looking at the bug #555178, I now verify fedora team's problem, my comment is below: I have verified this problem, and committed a fix that should be available later on today with the next bugzilla update, so fedora scripts should work again for the function Product.get_products what happened basically is that upstream had in their previous version of bugzilla the fucntion Product.get_products which we had also in RH bugzilla 3.2, and that was the function used by fedora scripts and it was returning the product description and other product details, we also had in our RH 3.2 a function we created called Product.get that was returning a structure used by our ajax rpc and upstream didn't have this function. in upstream bugzilla 3.4 they renamed Product.get_products to Product.get and made calling both functions call the same code in the line: BEGIN { *get_products = \&get } and that was causing the problem, I added for now Product.get_products as a separate function again to our RH bugzilla 3.4 until we merge the 2 functions. Regards, Noura
Hi Dave, Now I am thinking what would be the best way to merge the 2 functions Product.get and Product.get_products so that we get the upstream returned values and also the structure we need for our ajax rpc currently this is the difference: RH BZ 3.4 Product.get returns: $VAR1 = { 'TestProduct' => [ [ 'ipw2100-firmware', 'TestComponent' ], [ 'unspecified' ], ['---'] ], 'TestProduct2' => [ [ 'ipw2100-firmware2', 'TestComponent2' ], [ '1.0' ], ['---'] ], }; RH BZ 3.4 Product.get_products Data: $VAR1 = { 'products' => [ { 'internals' => { 'defaultmilestone' => '---', 'votesperuser' => '0', 'name' => 'TestProduct', 'classification_id' => '1', 'milestoneurl' => '', 'maxvotesperbug' => '10000', 'description' => 'This is a test', 'votestoconfirm' => '0', 'isactive' => '1', 'id' => '1' }, 'name' => 'TestProduct', 'id' => '1', 'description' => 'This is a test' }, { 'internals' => { 'defaultmilestone' => '---', 'votesperuser' => '0', 'name' => 'TestProduct2', 'classification_id' => '1', 'milestoneurl' => '', 'maxvotesperbug' => '10000', 'description' => 'This is a test', 'votestoconfirm' => '0', 'isactive' => '1', 'id' => '2' }, 'name' => 'TestProduct2', 'id' => '2', 'description' => 'This is a test' } ] }; so maybe we can add the products hash from Product.get as a hash key to the hash returned from Product.get_products , but then we should make the ajax rpc picks up only that has element to get the list of component, versions, and milestones? then we would be calling the merged function Product.get and having the same line as upstream BEGIN { *get_products = \&get } what do you think? if that sounds good to you, i can start merging the functions and fixing the ajax rpc call. Regards, Noura
Noura. I agree that the end result is that we want to match the return structure of the upstream code. We need to merge Product.get and Product.get_products. But I want us to extend the Product.get to provide the extra data that we need for our calls such as Ajax, etc. So when doing this make sure we have in the new version of Product.get: 1) It needs to take 'names' in addition to 'ids'. 2) It needs to return components, versions, milestones, either in their own top level hash key or as part of 'internals'. So the return structure can either be: Data: $VAR1 = { 'products' => [ { 'internals' => { 'defaultmilestone' => '---', 'votesperuser' => '0', 'name' => 'TestProduct', 'classification_id' => '1', 'milestoneurl' => '', 'maxvotesperbug' => '10000', 'description' => 'This is a test', 'votestoconfirm' => '0', 'isactive' => '1', 'id' => '1' }, 'name' => 'TestProduct', 'id' => '1', 'description' => 'This is a test' 'components' => [ # list of comp hashes ], 'versions' => [ # list of version hashes ], 'milestones' => [ # list of milestone hashes ], }, ] }; Data: $VAR1 = { 'products' => [ { 'internals' => { 'defaultmilestone' => '---', 'votesperuser' => '0', 'name' => 'TestProduct', 'classification_id' => '1', 'milestoneurl' => '', 'maxvotesperbug' => '10000', 'description' => 'This is a test', 'votestoconfirm' => '0', 'isactive' => '1', 'id' => '1', 'components' => [ # list of comp hashes ], 'versions' => [ # list of version hashes ], 'milestones' => [ # list of milestone hashes ], }, 'name' => 'TestProduct', 'id' => '1', 'description' => 'This is a test' }, ] }; There is some similar work going on upstream with new web service methods to give extra data such as Product.components that we could work together on. https://bugzilla.mozilla.org/show_bug.cgi?id=424921 There he is using some utility functions such as _get_component_attr() to return the data hashes for the component objects. We could use a _get_product_attr() function that returns the proper data hash for each of the products being returned. And in turn _get_product_attr() can call _get_component_attr() for each of the component objects. Same for milestones and versions. One additional question is should we have a param that must be passed in that if not used, does not return components, versions, and milestones? I think so since otherwise the returned data would be very large if a client only wanted a list of product descriptions for example. Thanks for working on this Noura Dave
Hi Dave, So do you think I should work on merging the 2 functions, and change our ajax rpc to use the new structure after the merge? or work on the upstream Product.components, and create Product.versions and Product.milestones and use that for our ajax rpc? I think if what we have currently is working for the users and there is no need really for the merge, then it is better if we leave it as is and work on those upstream fuctions to use them for our rpc ajax. then we can remove our current redhat Product.get and rename Product.get_products to be Product.get which does what the upstream function does. what do you think? Thanks, Noura
(In reply to comment #11) > Hi Dave, > > So do you think I should work on merging the 2 functions, and change our ajax > rpc to use the new structure after the merge? or work on the upstream > Product.components, and create Product.versions and Product.milestones and use > that for our ajax rpc? > I think if what we have currently is working for the users and there is no need > really for the merge, then it is better if we leave it as is and work on those > upstream fuctions to use them for our rpc ajax. then we can remove our current > redhat Product.get and rename Product.get_products to be Product.get which does > what the upstream function does. > > what do you think? I think you are right Noura. It possibly would be too much extra work to merge the two functions when the upstream is moving towards having separate functions for components, versions, and milestones anyway. Let's leave the two functions as they are for now. We need a reminder bug to tell us to go back and do the function rename when the other functions are done though. I believe there is already a Product.components function in progress upstream already so if you want you can do a review on that one for the author. If there is not currently a bug upstream for the Product.versions and Product.milestones functions, then feel free to start those up if you have time. Once the Product.components one is finished the others will be nearly identical so shouldn't take too much time to make. Thanks Dave
Red Hat has now upgraded to Bugzilla 3.6 and this bug will now be reassigned to that version. It would be helpful to the Bugzilla Development Team if this bug is verified to still be an issue with the latest version. If it is no longer an issue, then feel free to close, otherwise please comment that it is still a problem and we will try to address the issue as soon as we can. Thanks Bugzilla Development Team
We are now following upstream's Product.get, with a customisation to get the names only and another customisations to get the release values for a product. The documentation has been updated with our customisation. -- simon