On separate admin domain, reviews are not saved with correct store ID

[CNanninga]

Preconditions

1. Magento 2.2.5
2. Have only a single store configured on the install
3. VERY IMPORTANT: Admin is on a different domain than the front-end store. e.g., front-end is www.example.com, but admin.example.com is a domain that's been configured to load the admin view.
4. Set the value of MAGERUN_TYPE to "store" and the value of MAGE_RUNCODE to "admin" via server configuration

Steps to reproduce

1. Place a review for a product on the front-end, which will initially go into Pending status.
2. The review is associated appropriately with store ID 1 (and 0)
3. In the admin, view the review, mark as Approved, and save.

Expected result

1. The review remains associated with store ID 1 (i.e., its "visibility", based on having a record in the table review_store)

Actual result

1. The record in review_store associating the review with store ID 1 is deleted, leaving only a record for store 0, and the store no longer has visibility in any front-end store.

Additional information

Under the hood, this is a result of the user's "store" cookie being used (incorrectly) to derive the appropriate store context in many areas of the admin.

In \Magento\Review\Block\Adminhtml\Edit\Form::prepareForm, a check is made for whether there is only a single store on the Magento install. If not, a visible stores multi-select is added to the form, and this issue does not occur. If it _is a single store install, only a hidden input with the store ID is added to the form.

The value given to this hidden input is not derived from the store actually associated with the review. It is derived from \Magento\Store\Model\StoreManager::getStore (with no store ID passed in), which in turn gets the store ID from \Magento\Store\Model\StoreResolver::getCurrentStoreId. This method gets the store ID from a request param if it exists (it doesn't in this case), or else gets it from the "store" cookie.

If the admin is on the same domain as the front-end (e.g., www.example.com/backend), this ends up working. If the admin is on a different domain and therefore the Magento run code has been directly set to the admin store code, this cookie has the ID 0.

[magento-engcom-team]

Hi @CNanninga. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento-engcom-team give me {$VERSION} instance

where {$VERSION} is version tags (starting from 2.2.0+) or develop branches (2.2-develop +).
For more details, please, review the Magento Contributor Assistant documentation.

@CNanninga do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• yes
• no

[engcom-backlog-nickolas]

Hello @CNanninga, thank you for your report. I cannot reproduce this issue.

Could you please correct my steps, or add more details?

[engcom-backlog-nickolas]

@CNanninga, we are closing this issue due to inactivity. If you'd like to update it, please reopen the issue.

[hostep]

@engcom-backlog-nickolas: can you please test this again, by not using a subdomain for the admin domain, but an actually different domain? Subdomains inherit the cookies from the main domain, so in this case the bug probably won't trigger.

(I'm not saying the bug exists, I'm just saying you didn't follow the exact steps to reproduce, because in the example of @CNanninga he didn't use a subdomain)

[CNanninga]

@engcom-backlog-nickolas - I'd also point out that it would be helpful if your demonstration could also include explicitly checking the value of the "store" cookie. If it's "admin" when you are editing the review in the admin, I believe the bug will occur. (We actually did use a sub-domain for admin, but our Nginx configuration is set to explicitly set a Magento run code for the admin store on that sub-domain, so we do end up with a different cookie value, specifically associated with the admin.site.com domain.)

Haven't yet had a chance to do all the local setup required (including the aforementioned Nginx configuration) to verify this on a vanilla install. And I don't think getting an auto-deployed instance via the Git comment would help, as I assume there wouldn't be a way to set it up with a separate admin domain.

@CNanninga, we cannot reproduce the issue by the steps you provided.