0

Strange issue here...

This project has been live for some years, there are about 40k skus, and around 15k of sales & customers. I must say stock management has been used sometimes, but this project has never used stock quantity until now, they have only used stock status feature

I am trying to enable cataloginventory_options_can_subtract (that's the first option, in Catalog Inventory config section), but it seems that web request never ends, even in our local environment (with no timeout limits) it loads eternally

Enabling or disabling the different indexes does not make any change

So, question is: which code, or event, is fired while saving this config change? So I can give a look, and try to patch this, via shell script, or something

I'd try to change the parameter directly in core_config_data database table, and then reindex or something like that... but I'd take a look better to the code I am asking for, to be sure this won't affect in some way the integrity of the store... Any tips?

2
1
+100

So, which event is fired while saving this config change:

There are two events directly dispatched during this process:

The first one is admin_system_config_changed_section_cataloginventory and is dispatched in the saveAction of the app/code/core/Mage/Adminhtml/controllers/System/ConfigController.php right after the config is being saved to the database.

The app/core/core/Mage/CatalogInventory/etc/config.xml declares an observer on this specific event:

<admin_system_config_changed_section_cataloginventory>
    <observers>
        <inventory>
            <class>cataloginventory/observer</class>
            <method>updateItemsStockUponConfigChange</method>
        </inventory>
    </observers>
</admin_system_config_changed_section_cataloginventory>

Where the observer function looks like this:

public function updateItemsStockUponConfigChange($observer)
{
    Mage::getResourceSingleton('cataloginventory/stock')->updateSetOutOfStock();
    Mage::getResourceSingleton('cataloginventory/stock')->updateSetInStock();
    Mage::getResourceSingleton('cataloginventory/stock')->updateLowStockDate();
    return $this;
}

On the other hand, under the app/code/core/Mage/Index/etc/config.xml you will find the following code:

<core_config_data_save_commit_after>
    <observers>
        <index>
            <class>index/observer</class>
            <method>processConfigDataSave</method>
        </index>
    </observers>
</core_config_data_save_commit_after>

This core_config_data_save_commit_after event is being dispatched under the app/code/core/Mage/Core/Model/Abstract.php in the afterCommitCallback function. (Note that this event is dispatched for every system config section save, not only for the cataloginventory section).

Its name tells it all, it is dispatched after the commit, you can find the details in the save function:

$this->_beforeSave();
if ($this->_dataSaveAllowed) {
    $this->_getResource()->save($this);
    $this->_afterSave();
}
$this->_getResource()->addCommitCallback(array($this, 'afterCommitCallback'))
    ->commit();

The observer function linked to that event looks like this:

public function processConfigDataSave(Varien_Event_Observer $observer)
{
    $configData = $observer->getEvent()->getConfigData();
    $this->_indexer->processEntityAction(
        $configData,
        Mage_Core_Model_Config_Data::ENTITY,
        Mage_Index_Model_Event::TYPE_SAVE
    );
}

So to me, those two observers are the suspect you should investigate.

More information about them:

  • The CatalogInventory observer function calls 3 different functions, each of them is making updates to the stock_item database table, which could be a huge resource consumer as you're dealing with a huge database.
  • The Index observer function on the other hand processes the index related to the config section saved. And there is definitely an index related to the cataloginventory stock.

Going further:

It's good to note that the processEntityAction method of the app/code/core/Mage/Index/Model/Indexer.php (called by the Index observer function) also dispatched two events:

  • start_process_event (followed by the event type name)
  • end_process_event (followed by the event type name)

Even if the first one is not used, the second one is being observer by app/code/core/Mage/CatalogInventory/etc/config.xml:

<end_process_event_cataloginventory_stock_item_save>
    <observers>
        <cataloginventory>
            <class>cataloginventory/observer</class>
            <method>reindexProductsMassAction</method>
        </cataloginventory>
    </observers>
</end_process_event_cataloginventory_stock_item_save>

Where the observer function is a reindex:

public function reindexProductsMassAction($observer)
{
    Mage::getSingleton('index/indexer')->indexEvents(
        Mage_Catalog_Model_Product::ENTITY, Mage_Index_Model_Event::TYPE_MASS_ACTION
    );
}

This is a good example of the differences between what events are being dispatched during a process explicitely and what events are being dispatched during a process implicitely.

1
  • Excellent! This is exactly what I was requiring, no need to wait for more answers. Points for you Mar 14 '16 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.