REST Api product Catalog Not Responding to Changes In Store View

[Spittal]

Hello,

Me and my company are developing an Angular site for a client that communicates with Magento2 over Magento's build in REST api.

One of the requirements of the site is that there are multiple locals, that have slightly different catalogs of products. In this case we have a US store and EU store that have very similar but different products.

I'm using the API endpoint
{{API_URL}}/rest/{{STORE_VIEW_CODE}}/V1/products
With some extra searchCriteria

The problem is when I change the "{{STORE_VIEW_CODE}}" from one store view code to another, I see absolutely no difference in the payloads even though based on my configuration I should see different results. I've even confirmed that my store view changes are indeed applying by using the Luma front-end on my Magento2 install.

This is slightly hard to explain so here's a a gif of the behaviour.

http://i.imgur.com/gBUObKX.gifv

As you can see from the GIF the "Websites" configuration of the product seems to have NO effect on the returning catalog call.

I would expect to see that turning off the product in specific store views would remove the product from the REST api call.

[pboisvert]

Mark--can you check for expected behavior and file an issue if needed?

[Bbbrinks]

Seems like all prodcuts in the "Root Category" of the store are returned in the rest api. No filtering is done based on the product configuration.

I don't know what the expected behavior would be for this. But it might be logical if the same products are shown on the front-end as in the REST api.

[misha-kotov]

Internal issue is MAGETWO-63667. Also, related GH ticket: #8121

[jdorrance]

any update on this bug?

[pareshe]

there is patch available for this ?

[misha-kotov]

This has been fixed in the develop branch

[pareshe]

Where can i see patch or commit.

[korostii]

Hi @misha-kotov, I hate to underline the obvious, but if the bug was discovered on 2.1.x and then reportedly "fixed", it is commonly expected to see that fix in the closest patch (2.1.x) release.

To be honest, I don't see how is "fixed in the develop branch" an acceptable resolution to an acknowledged bug. Until the fix is officially released, a lot of the users are still struggling with it.
In my opinion, having these patches added into the nearest 2.1.x (or 2.1.x.x) releases right away would be perfect, but that doesn't seem to be happening, so...

Could you please at least include a short piece of information that will explain to an ordinary merchant, how he\she can benefit from such s fix?
Something along the following lines (not sure which of these is recommended by Magento, Inc.):

• patch the core files according to the commits referenced (make sure to backup the patch files and re-apply them every time you update the Magento to the next released version)
• fork the repository, and cherry-pick these commits into your local 2.1 branch and use that instead of a downloaded or composer-installed version (Although I believe this was not officially recommended if you don't plan to contribute to the project)
• the option above plus make a pull request pointing back into 2.1-develop
• write a module that'll do these changes "the right way" using all those shiny extends and overrides and plugins and observers and so on in order to avoid patching the core directly

Keeping the issue open until the fix appears in a 2.1.x release is also a feasible option.

[misha-kotov]

Hi @korostii , @pareshe
Totally agree with you about the need to provide a solution for Magento versions where the issue is reported (2.1.x in this case). However, our process has always been to close issues that have been in develop branch - and this has been done for a long time - due to the ability by developers to find the needed commits.
From a point of view of the developer, if you have the repo cloned, you can grep the Git logs for the internal ticket number provided by Magento. It'll look something like this:
clone develop from [email protected]:magento/magento2.git
git log | grep -C3 MAGETWO-63667
The output will give you the needed commits.

Alternatively, you can ask the person closing the ticket to provide you the commits (arguably easier, but you'll need to wait for them to get back to you). In this case they are the following:
764284f9dd41b00f18401fd4c701366a7d4c9a65
4b2b152637711ce400dba609b20bbb20ebf0bac5
4cd97881c31051ee708fc334db33e79627765300
b026e9b0f1b2b215ed31819f381f353f6b132e47
519398d298a1332763069e73da1e13f3e9d390b4

Note: adding .patch to the end of the commit url will turn it into a patch: example.

Hope this helps.

[Ctucker9233]

@magento-engcom-team I don't see these fixes in 2.2. Is a backport necessary?

[m2-assistant]

Hi @engcom-backlog-nazar. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 4. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento-engcom-team give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 5. Verify that the issue is reproducible on 2.2-develop branch.

  Details

  - Add the comment @magento-engcom-team give me 2.2-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.2-develop branch, please add the label Reproduced on 2.2.x

• 6. Add label Issue: Confirmed once verification is complete.

• 7. Make sure that automatic system confirms that report has been added to the backlog.

[ghost]

Hi @Ctucker9233 this issue not reproducible on 2.2-develop branch.