Magento 2 REST API - Updating a single category also updates other attributes to not use the default value

[JoryHogeveen]

Preconditions and environment

• Magento version: 2.4.7-p3
• Anything else that would help a developer reproduce the bug

I've already posted this on StackExchange:
https://magento.stackexchange.com/questions/375887/magento-2-rest-api-updating-a-single-category-also-updates-other-attributes-to

Due to the nature of this issue I really think it's a bug. And if not, an documentation issue.

Steps to reproduce

1. Create product with default values like name etc.
2. Update Product for a store_code only using REST API and only provide the data for a single custom attribute.
3. The updated product now has overrides on many other attributes even though this data was not provided by the API

Expected result

The API should only update the data you send to it.

Actual result

The API updates a lot of other attributes like name, visibility etc.

Even though this will update that particular attribute just fine, it will also set several other attributes to overwrite the default value.

See example return under additional information. All attributes seen in the response below are not set to default anymore. Note that many other attributes, also store-view attributes among them like "page_layout", are still set to default...

I have no explanation as to why some attributes are switched to not use the default anymore and some others are not. Hope someone can help me with this as I am totally lost after hours of testing.

Additional information

API request:

POST: /store_view_code/V1/products/

{
    "product": {
        "sku": "testSku",
        "custom_attributes": [
            {
                "attribute_code": "text_attribute like description or something else",
                "value": "the translated value"
            }
        ]
   }
}

API response:

{
   "id":123, // global
   "sku":"testSku", // global
   "name":"The Product title",  // Not set to default anymore.
   "attribute_set_id":4, // global
   "price":123, // Not set to default anymore.
   "status":0, // Not set to default anymore.
   "visibility":4, // Not set to default anymore.
   "type_id":"simple", // global
   "created_at":"2024-12-17 18:35:19",
   "updated_at":"2024-12-18 22:29:10",
   "extension_attributes":{
      "website_ids":[
          // Hopefully not overwritten, did not test this yet.
      ],
      "stock_item":{
          // Full stock item, not store view related.
      }
   },
   "options":[
      
   ],
   "media_gallery_entries":[
      // Hopefully not overwritten, did not test this yet.
   ],
   "custom_attributes":[

      // All attributes below not set to default anymore.
      // Note that many other attributes, also store-view attributes among them like "page_layout", are still set to default...

      {
         "attribute_code": "text_attribute like description or something else",
         "value": "the translated value" // This is ok! And should be the only attribute that was changed.
      }
      {
         "attribute_code":"url_key",
         "value":"the-product-url-key" // Not set to default anymore.
      },
      {
         "attribute_code":"options_container",
         "value":"container2" // Not set to default anymore.
      },
      {
         "attribute_code":"tax_class_id",
         "value":"2" // Not set to default anymore. (website scope)
      },
      {
         "attribute_code":"required_options",
         "value":"0" // No idea.
      },
      {
         "attribute_code":"has_options",
         "value":"0" // No idea.
      },
      {
         "attribute_code":"category_ids",
         "value":[
            // Hopefully not overwritten, did not test this yet.
         ]
      }
   ]
}

Release note

I've set this to severity S0 as with the current state it will override important attributes like visibility, status and name without intent. This can create big issues on live instances where users could suddenly see hidden products in the catalog or even products with incorrect data.

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant]

Hi @JoryHogeveen. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant]

Hi @engcom-Bravo. 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).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.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. Add label Issue: Confirmed once verification is complete.
• 6. Make sure that automatic system confirms that report has been added to the backlog.

[bharatkumawaty7]

Hi @JoryHogeveen @engcom-Bravo,

I have tried reproducing the issue on the magento 2.4.7-p3 but the issue is not reproduceable to me. I have changed the value for the description for the specific product on store level. the description value was updated successfully and overwritten the default value. But the other product attributes were still selected as set to default value. Please check the screenshots below and correct me if i am wrong or provide me some additional details to reproduce the issue.

Updated value of description at store level

Product name and other attributes are still selected to use default value and unchanged.

[JoryHogeveen]

@bharatkumawaty7
Thank you for jumping in here!
I see that you are testing with the default store code, could you please try another store view code?

[bharatkumawaty7]

Hi @JoryHogeveen

I have tried with the different store view code as well but it seems working fine. Please check here with attached screenshots.

[JoryHogeveen]

Hi @bharatkumawaty7
Thank you for checking!
I verified again on my own installation again and cannot explain this, but I also see the same behavior now..

My REST workflow was as follows:

1. The first step I took prior to these store view updates was to create the products in the "all" storecode with minimal data (sku, name, price and a brand attribute).
2. Then I ran a bulk loop to import all store specific information. (name override, description and short_description).
3. After that I checked the results and saw that a lot of other info, like status, visibility, etc., was also overridden.

I could reproduce this consistently, hence the bug report, and now I cannot anymore. Everything was done through the REST API.

It might be relevant to mention that I did do a rebuild in the meantime and the cache and indexes are also refreshed several times since this report.

I wouldn't expect cache or indexes giving troubles here since they didn't mention a refresh requirement + the current situation is still that the default values are overridden. I also didn't do a composer update so the lock file should still install the same package versions.

I've already prepared a SQL script to remove all EAV overrides that have the same value as the default storecode (https://gist.github.com/JoryHogeveen/7aa4fa8a859cb030319cd300cbc745b6).

Can you think of any reason why the initial issue occurred?

Thank you again for taking the time to look into this topic.