Error with xmlrpc protocole. Error details : error 103 : Default Product Listing Sort by not exists on Available Product Listing Sort By

[Réal Carbonneau]

When the "Default Sorting method" for a product category in OpenERP is set to a value other than "Use Config Settings", the following error occurs (see below).

There already seems to be a bug opened and closed for this (Bug #588198), and a reference to another bug (Bug #876312).

As mentioned by others, the workaround is to set the value to "Use Config Settings".

Error with xmlrpc protocole. Error details : error 103 : Default Product Listing Sort by not exists on Available Product Listing Sort By

<class 'xmlrpclib.Fault'>
Traceback (most recent call last):
  File "/opt/openerp/server/openerp/addons/base_external_referentials/decorator.py", line 130, in wrapper
    response = func(self, import_cr, uid, external_session, resource, *args, **kwargs)
  File "/opt/openerp/server/openerp/addons/magentoerpconnect/magerp_osv.py", line 46, in _transform_and_send_one_resource
    return self.mag_transform_and_send_one_resource(cr, uid, external_session, *args, **kwargs)
  File "/opt/openerp/server/openerp/addons/base_external_referentials/external_osv.py", line 1094, in _transform_and_send_one_resource
    return self.send_to_external(cr, uid, external_session, {resource_id : resource}, mapping, mapping_id, update_date, context=context)
  File "/opt/openerp/server/openerp/addons/base_external_referentials/external_osv.py", line 977, in send_to_external
    self.ext_update(cr, uid, external_session, resources_to_update, mapping, mapping_id, context=context)
  File "/opt/openerp/server/openerp/addons/magentoerpconnect/product.py", line 154, in ext_update
    external_session.connection.call('catalog_category.update', [ext_id, resource[main_lang], False])
  File "/opt/openerp/server/openerp/addons/magentoerpconnect/magerp_osv.py", line 222, in call
    res = self.ser.call(self.session, method, arguments)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1199, in __call__
    return self.__send(self.__name, args)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib/python2.6/xmlrpclib.py", line 1253, in request
    return self._parse_response(h.getfile(), sock)
  File "/usr/lib/python2.6/xmlrpclib.py", line 1392, in _parse_response
    return u.close()
  File "/usr/lib/python2.6/xmlrpclib.py", line 838, in close
    raise Fault(**self._stack[0])
Fault: <Fault 103: 'Default Product Listing Sort by not exists on Available Product Listing Sort By'>

[Alexandre Fayolle - camptocamp (alexandre-fayolle-c2c)]

Which version of Magento are you using ?

--
Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 79 26 57 94

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

[Réal Carbonneau (real-carbonneau)]

Magento ver. 1.7.0.1

Recent Magento Module from two days ago (where can I see the version?)
bzr branch lp:magentoerpconnect/magento-module-oerp6.x-stable

openerp-6.1-20121024-233156

Recent Magento OpenERP Connector from two days ago (where can I see the version?)
bzr branch lp:magentoerpconnect/oerp6.1-stable magentoerpconnect
bzr branch lp:e-commerce-addons/oerp6.1-stable e-commerce-addons
bzr branch lp:openobject-extension/oerp6.1-stable openobject-extension
bzr branch lp:product-extra-addons/oerp6.1-stable product-extra-addons

[Stefan Rijnhart (Opener) (stefan-opener)]

Using Magento 1.6.1.0. Got the same problem.

The error originates from app/code/core/Mage/Catalog/Model/Category/Attribute/Backend/Sortby.php, when the default sorting field is not in the list of available sort orders. This is always the case when 'Use Default Config' is set, because then the list is empty.

I gather from the PHP code in this file that the connector should set up an array value for a field 'use_post_data_config' that contains 'available_sort_by' if 'Use Default Config' is set on the category. Also, the field 'available_sort_by' should then by absent from the list of values sent to Magento. Only then will it retrieve the list of default sorting fields to check if the sorting field for this particular category is valid.

I have added a mapping line to the template and it gets sent over the wire as expected. Unfortunately, when Magento reads it out using "$object->getData('use_post_data_config')" it is not there so my problem is not yet solved.

Here is the mapping line:

magentoerpconnect.mag1500_product_category_use_post_data_config,magentoerpconnect.mag1500_product_category,use_post_data_config,,out,function,unicode,,False,False,"use_config_fields = []
if 'default_sort_by' in resource:
    cat_attr_option = 'None'
    if resource['default_sort_by']:
        cat_attr_option = self.pool.get('magerp.product_category_attribute_options').browse(cr, uid, resource['default_sort_by'][0], context=context)
    if cat_attr_option.value == 'None':
        use_config_fields.append('default_sort_by')
if resource.get('use_default_available_sort_by'):
    use_config_fields.append(u'available_sort_by')
if use_config_fields:
    result = [(u'use_post_data_config', use_config_fields)]
else:
    result = []"

I would like to know if I am on the right path. Has anyone got a notion of this 'use_post_data_config' key, and do you think it should be used in the connector like I think it does?

[Stefan Rijnhart (Opener) (stefan-opener)]

The category create API in Magento intercepts a magic value 'use_config' for default sort by, as well as available sorting options. However, the update API in Magento does not. Got it working by patching the Magento code accordingly. See http://www.magentocommerce.com/bug-tracking/issue/?issue=15011. Of course, I also had to change the mapping lines (discarding the one mentioned in my previous post) to set this magic value.

Additionally, the error occurred when only the name of the category was updated (as in multiple languages setup). That is because validation on category update in Magento is broken. It validates the whole record, but it does not accept an empty value for 'available sorting options'. Unfortunately, the empty value seems to be the internal representation of 'Use configuration settings' for the available sorting options, once the 'use_config' magic value has been intercepted. So when only the category name is updated, the internal representation of untouched fields is invalidated. I worked around this problem by adding a context option that would trigger a full read on a resource for alternate translations.

Will post my branches, but again they depend on a patched Magento installation.

[Guewen Baconnier @ Camptocamp (gbaconnier-c2c)]

Did you try to run this query?

    update eav_attribute set is_required = 0 where attribute_code = 'available_sort_by';

Seen in lp:876312 (comment #1)

[Stefan Rijnhart (Opener) (stefan-opener)]

Hi Guewen, thanks for the pointer. If validation is indeed only triggered on required fields, I can see that setting 'is_required' to 0 for 'available_sort_by' and 'default_sort_by' allows for setting these fields to 'Use default configuration'.

With my patches for magentoerpconnect and the Magento API (which I believe to be very clean, they only make the update API consistent with the create API), you can have the full kaboodle (I just tested all different combinations):

Use config setting for available sorting methods and for default sorting method.
Use custom available sorting methods but use default sorting method.
Use custom available sorting methods and custom default sorting method
Use config setting for available sorting methods but custom default sorting method.

Best thing is that when you then get the 'Default Product Listing Sort by not exists on Available Product Listing Sort By' warning, it signals an actual inconsistency in your product configuration!

[Stefan Rijnhart (Opener) (stefan-opener)]

This bug is fixed by the associated branches, which have been merged. These branches however, depend on a patch on the Magento file tree. The patch fixes the API consistency between category update and create methods. I filed an issue here: http://www.magentocommerce.com/bug-tracking/issue/?issue=15011. Because you need an account to view the Magento issue tracker I am copying in the patch here.

The patch is against Magento 1.6.0.2 but the offending code seems untouched in 1.7.x