Skip to content

#29174 Add save_rewrites_history to categories via API #29205

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

Conversation

amenk
Copy link
Contributor

@amenk amenk commented Jul 20, 2020

Support save_rewrites_history to categories API

Description (*)

See #29174

Fixed Issues (if relevant)

  1. Fixes Category API should support save_rewrites_history for consistency reasons #29174, [Issue] #29174 Add save_rewrites_history to categories via API #30240

Manual testing scenarios (*)

See example in #29174

Contribution checklist (*)

  • Pull request has a meaningful description of its purpose
  • All commits are accompanied by meaningful commit messages
  • All new or changed code is covered with unit/integration tests (if applicable)
  • All automated tests passed successfully (all builds are green)

Resolved issues:

  1. resolves [Issue] #29174 Add save_rewrites_history to categories via API #30240: Category API should support save_rewrites_history for consistency reasons #29174 Add save_rewrites_history to categories via API

@m2-assistant
Copy link

m2-assistant bot commented Jul 20, 2020

Hi @amenk. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

  • @magento give me test instance - deploy test instance based on PR changes
  • @magento give me 2.4-develop instance - deploy vanilla Magento instance

❗ Automated tests can be triggered manually with an appropriate comment:

  • @magento run all tests - run or re-run all required tests against the PR changes
  • @magento run <test-build(s)> - run or re-run specific test build(s)
    For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names. Allowed build names are:

  1. Database Compare
  2. Functional Tests CE
  3. Functional Tests EE,
  4. Functional Tests B2B
  5. Integration Tests
  6. Magento Health Index
  7. Sample Data Tests CE
  8. Sample Data Tests EE
  9. Sample Data Tests B2B
  10. Static Tests
  11. Unit Tests
  12. WebAPI Tests

You can find more information about the builds here

ℹ️ Please run only needed test builds instead of all when developing. Please run all test builds before sending your PR for review.

For more details, please, review the Magento Contributor Guide documentation.

⚠️ According to the Magento Contribution requirements, all Pull Requests 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 Pull Requests happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

🎥 You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

✏️ Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

* Support save_rewrites_history in save
Copy link
Contributor

@swnsma swnsma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @amenk!

Thank you for your contribution!
Could you please check my comments?

Could you, also, please add coverage with webapi-functional tests?
Thank you!

@@ -82,6 +82,10 @@ public function save(\Magento\Catalog\Api\Data\CategoryInterface $category)
$existingData = array_diff_key($existingData, array_flip(['path', 'level', 'parent_id']));
$existingData['store_id'] = $storeId;

if ($category->getData('save_rewrites_history', null) !== null) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be placed in Magento_CatalogUrlRewrite, not in Magento_Catalog.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you have a clue how we could do that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@swnsma

In the first place my code is very similar to the solution products, just the categories are persisted differently and I am wondering which is the better way :)
I.e. if we change it for categories, we might need to adapt products as well.

I see several options:

  1. Mess with \Magento\Catalog\Model\CategoryRepository::getExtensibleDataObjectConverter (which is already deprecated)
  2. Intercept a different method, in the before save event, and somehow get the info that rewrites should be created from the request
  3. .... ?

Help is very much appreciated :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem that approach is lead to violation of modularity.
I see that for save from Adminhtml area, it uses observer to set a value and ResourceModel to save:
observer name="category_save_rewrites_history_setter"

Could you play somehow with \Magento\Catalog\Model\CategoryRepository::getExtensibleDataObjectConverter ? (the method is deprecated because class should be injected into the constructor parameters).

I see that it can handle custom attributes: \Magento\Framework\Api\ExtensibleDataObjectConverter::processCustomAttributes
Could we check why it does not help to solve our issue?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problem that approach is lead to violation of modularity.
absolutely

I see that for save from Adminhtml area, it uses observer to set a value and ResourceModel to save:
observer name="category_save_rewrites_history_setter"

yes, but no access to what was sent via the API, here

Could you play somehow with \Magento\Catalog\Model\CategoryRepository::getExtensibleDataObjectConverter ? (the
method is deprecated because class should be injected into the constructor parameters).
I see that it can handle custom attributes:
\Magento\Framework\Api\ExtensibleDataObjectConverter::processCustomAttributes
Could we check why it does not help to solve our issue?

Maybe ... I am still wondering if that flag should be a custom attribute at all

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, I really would like to avoid such complications.
In such a case, it will be nice to have a mechanism for extension of Custom Attributes with not only EAV attributes but also with some configuration (more XML!).
But we already have Extension Attributes, which, could be used for this.

I prefer to look into two possible ways:

  1. A short one - look into how we are saving category.
    Probably, we need to just copy 'all other' fields from category data as it works for the product:
    $productDataArray = $this->extensibleDataObjectConverter
  2. A long one but more solid - look if we can replace usage of a custom attribute for extension attributes.
    But it still is required to think about possible BC breaks (at least for products, where it works previously).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your feedback @swnsma - I choose the blue pill (1.) for now. Let's see what the full test suite say.
I might still be BC breaking in a way, that some module does not expect all data to be copied in the repository's save, but it is very unlikely.

Actually I am not sure how repositories are supposed to work: Whether they should the attributes to the ones clearly specified (like EAV attributes) or not.

Option 2. would be great to implement, because it also saves us from all the hassle in InputParamsResolver, but I just don't have the resources to do that now -- at least we would have a integration test now if this get's merged :)

In the end of the day, I am not even sure if this setData() approach is nice to trigger the URL key regeneration - maybe somebody has even some better idea here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not really like the idea to pass all data with setData(). It also a hack but, at least, it does not provide modularity issue 😅

But, in general, it will be nice to ask someone else for additional ideas.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would prefer option 1 if it is enough to solve the issue.
Looks like the safest and the easiest way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is like it is currently implemented in the PR... Can you take over and fix the tests? Thanks in advance

@amenk
Copy link
Contributor Author

amenk commented Jul 21, 2020

Could you, also, please add coverage with webapi-functional tests?

I thought about doing that, yes :) Do you have some suggestion which test would be a good starting point.

@amenk
Copy link
Contributor Author

amenk commented Jul 21, 2020

I think I will use \Magento\Catalog\Api\CategoryRepositoryTest::testUpdate as a base test

@amenk
Copy link
Contributor Author

amenk commented Jul 21, 2020

@swnsma functional test added, no we just have to solve the architectural problem in
https://github.com/magento/magento2/pull/29205/files/00176f5a3a0c6671556ff28b66f437ffb1970060#diff-7493dc1498457624ac9529eacf844ff7

Feel free to adapt the pull request, if you have an idea how to fix it and now that a proper test is in place.

@amenk
Copy link
Contributor Author

amenk commented Jul 21, 2020

Actually there are tons of modularity problems between Catalog and CatalogUrlRewrite --- save_rewrites_history is used in Magento_Catalog and url_key of course as well ...

The simples possible fix for the full issue would be

Index: app/code/Magento/Catalog/Model/Category.php
===================================================================
--- app/code/Magento/Catalog/Model/Category.php	(revision b8c848b22083b369702bebc19af7ad74bfe83c27)
+++ app/code/Magento/Catalog/Model/Category.php	(date 1595352024085)
@@ -309,7 +309,9 @@
	 if ($this->customAttributesCodes === null) {
	     $this->customAttributesCodes = $this->getEavAttributesCodes($this->metadataService);
	     $this->customAttributesCodes = array_diff($this->customAttributesCodes, CategoryInterface::ATTRIBUTES);
+            $this->customAttributesCodes[] = 'save_rewrites_history';
	 }
	 return $this->customAttributesCodes;
     }

We could do something similar for products and get rid of the full file

app/code/Magento/CatalogUrlRewrite/Plugin/Webapi/Controller/Rest/InputParamsResolver.php

amenk added 2 commits July 25, 2020 13:24
…4-save-rewrites-for-categories

# Conflicts:
#	dev/tests/api-functional/testsuite/Magento/Catalog/Api/CategoryRepositoryTest.php
@amenk
Copy link
Contributor Author

amenk commented Jul 25, 2020

@magento run all tests

@amenk
Copy link
Contributor Author

amenk commented Jul 25, 2020

@magento run all tests

2 similar comments
@swnsma
Copy link
Contributor

swnsma commented Jul 26, 2020

@magento run all tests

@swnsma
Copy link
Contributor

swnsma commented Jul 27, 2020

@magento run all tests

@amenk
Copy link
Contributor Author

amenk commented Jul 28, 2020

But, in general, it will be nice to ask someone else for additional ideas.

@swnsma whom?

@ghost ghost assigned novikor Jul 31, 2020
@sidolov sidolov added the Priority: P2 A defect with this priority could have functionality issues which are not to expectations. label Aug 13, 2020
@engcom-Echo
Copy link
Contributor

@magento run all tests

@engcom-Echo
Copy link
Contributor

Failed functional tests not related to the changes in this PR

@swnsma swnsma self-requested a review September 30, 2020 06:38
@magento-engcom-team
Copy link
Contributor

Hi @swnsma, thank you for the review.
ENGCOM-8286 has been created to process this Pull Request
✳️ @swnsma, could you please add one of the following labels to the Pull Request?

Label Description
Auto-Tests: Covered All changes in Pull Request is covered by auto-tests
Auto-Tests: Not Covered Changes in Pull Request requires coverage by auto-tests
Auto-Tests: Not Required Changes in Pull Request does not require coverage by auto-tests

@swnsma swnsma added the Auto-Tests: Covered All changes in Pull Request is covered by auto-tests label Sep 30, 2020
@swnsma
Copy link
Contributor

swnsma commented Sep 30, 2020

@magento run Functional Tests EE, Functional Tests B2B

@engcom-Bravo engcom-Bravo self-assigned this Sep 30, 2020
@novikor novikor removed their assignment Sep 30, 2020
@engcom-Bravo
Copy link
Contributor

✔️ QA Passed

Manual testing scenario

  1. Go to Catalog - Categories and create a new Subcategory
  2. Open Swagger (http://magentositewname.domain/swagger)
  3. Generate Admin token via integrationAdminTokenServiceV1 POST /V1/integration/admin/token request
  4. Copy the generated token into api_key field and click **apply
    api_key_field
  5. Perform the catalogCategoryRepositoryV1 PUT /V1/categories/{id} request with the following Parameters:
  • id 2 (id of the previously created category)
  • body
{
    "category": {
    "id": 5,
    "parent_id": 2,
    "name": "new name",
    "is_active": true,
    "position": 0,
    "level": 0,
    "created_at": "string",
    "updated_at": "string",
    "path": "string",
    "include_in_menu": true,
    "extension_attributes": {},
    "custom_attributes": [
      {
        "attribute_code": "url_key",
        "value": "new name1"
      },{
        "attribute_code":"save_rewrites_history",
        "value":1
        }
      ]
     }
    }
  1. Verify if the Response body is correct.
    Example:
    resp_body
  2. Open database table url_rewrite

BEFORE applying changes provided in this PR, the old url_rewriew record has been removed, and only the new record existed
db_before11

db_before2

AFTER switching to the PR, the previous record is not removed
db_after1

@engcom-Bravo
Copy link
Contributor

@magento create issue

@m2-assistant
Copy link

m2-assistant bot commented Sep 30, 2020

Hi @amenk, thank you for your contribution!
Please, complete Contribution Survey, it will take less than a minute.
Your feedback will help us to improve contribution process.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Auto-Tests: Covered All changes in Pull Request is covered by auto-tests Award: bug fix Component: CatalogUrlRewrite help wanted Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Progress: accept QA: Added to Regression Scope Scenario was analysed and added to Regression Testing Scope Release Line: 2.4 Severity: S2 Major restrictions or short-term circumventions are required until a fix is available.
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

[Issue] #29174 Add save_rewrites_history to categories via API Category API should support save_rewrites_history for consistency reasons
8 participants