Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Quick question related to field manage_stock #3

Open
revington opened this issue Feb 5, 2021 · 5 comments
Open

Quick question related to field manage_stock #3

revington opened this issue Feb 5, 2021 · 5 comments

Comments

@revington
Copy link

Hey I'm new to VSF so excuse me if this question does not make any sense.
After setting up this module in an opencart shop and the indexer I'm able to feed data into VSF API but in the shop I have no available products. Products are there but to VSF they can not be purchased due to lack of stock.
I've been checking the code and as far as I can see the problem is that products don't have a defined manage_stock option which, to be honest, I have no clue what does it mean.

This option is present in the magento bridge and used by the capybara* theme
and here

So, back to my question: should this manage_stock option be set up by this module at export time?

*res.manageStock is set by the store from the manage_stock property

@themreza
Copy link
Contributor

themreza commented Feb 7, 2021

I don't think the manage_stock field is necessary. It's actually a Magento-specific field (https://magento.stackexchange.com/questions/316397/change-manage-stock-via-rest-api-on-magento-2).

In our implementation of VSF using this bridge we have products that are out of stock but are still imported.

However, we don't import disabled products.

One way to find out what's going on in your case is to check your ElasticSearch.

If you have the out-of-stock products in the product index, that means Vue Storefront itself is not showing the products (probably due to a config you can add in config/local.json). But if the products are not in ElasticSearch, it means either the bridge did not send them to ElasticSearch, or ElasticSearch didn't index them. In that case I would look at the indexer logs and inspect one of the product URLs in your browser (you may need to add page and pageSize parameters manually to the URL).

@revington
Copy link
Author

Thanks @themreza,

Products are being displayed in VSF so they are in elasticsearch but they look as they are out of stock.
localhost_3000_Abaco-Arcoiris-Madera-Azul
The question is: why?. The API is returning proper stock so this product should be available on VSF.

// Stock API call returns a quantity of 3
// http://localhost:8080/api/stock/check?sku=LD4457
{"code":200,"result":{"item_id":2178,"product_id":2178,"qty":3,"is_in_stock":true}}

And this, as far as I can see, is because the API is not returning the manage_stock field.
When config.stock.synchronize is set to true in VSF (default=true) stock is check per request against the VSF API which checks stock against OpenCart.

When VSF API manage_stock is falsy then stock.max becomes null (here) and manageQuantity becomes false.

Then the capybara theme will tell that this product is not available

My only way to make it work is to hardcode this value into the opencart platform so now manage_stock is true always.

{"code":200,"result":{"item_id":2178,"product_id":2178,"qty":3,"is_in_stock":true,"manage_stock":true}}

and it works as expected. But, to be honest I don't know what this manage_stock means.

@themreza
Copy link
Contributor

themreza commented Feb 8, 2021

Good find.

Unfortunately, that's one of the downsides of Vue Storefront -- fields that have made it into code without any explanation, primarily because that's how Magento works.

I checked our code and it looks like we changed Vue Storefront instead of adding the API field, but since it's more stable, do what you've done.

@revington
Copy link
Author

Should I PR this? If it is gonna stay looks like the correct thing to do but I'm having trouble trying to figure out what is the purpose of this field :(

@themreza
Copy link
Contributor

themreza commented Feb 9, 2021

Sure. It would be great if you collect all your findings and fixes as PRs and we can release them under its own branch as soon as you get a working setup.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants