You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an assembly's part is updated, it is not updating the timestamp on the assembly itself. This can cause the product page for the assembly to be out of date. The cache key on the product page in frontend relies on the cache_key of the Spree::Product. Since touching/saving a variant that is a part of the assembly does not update the assembly's updated_at timestamp, the page can be out of date, looking in stock when it is actually out of stock.
Recommended solution
In the variant decorator, we can simply add the following:
after_touch :touch_assemblies
def touch_assemblies
self.assemblies.map(&:touch)
end
This should reliably update the assembly variant and through it the product record's updated_at timestamp. I'm not certain that this will handle deferred variant's correctly, so an approach like this may work better on the product decorator.
The only concern I have about this solution is that it could cause infinite recursion. If a part touches an assembly that is a part of another assembly, touching it would trigger another round up the tree that could (in theory) loop back to the originating Part, causing infinite recursion.
Problem description
When an assembly's part is updated, it is not updating the timestamp on the assembly itself. This can cause the product page for the assembly to be out of date. The cache key on the product page in frontend relies on the cache_key of the Spree::Product. Since touching/saving a variant that is a part of the assembly does not update the assembly's updated_at timestamp, the page can be out of date, looking in stock when it is actually out of stock.
Recommended solution
In the variant decorator, we can simply add the following:
This should reliably update the assembly variant and through it the product record's updated_at timestamp. I'm not certain that this will handle deferred variant's correctly, so an approach like this may work better on the product decorator.
If no one sees an issue with this approach, I'm happy to submit a pull request.
The text was updated successfully, but these errors were encountered: