Skip to content

Replace hard-coded list of category attributes #28216

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

fredden
Copy link
Member

@fredden fredden commented May 13, 2020

Description

Magento\Catalog\Model\Category\DataProvider::getFieldsMap() had a hard-coded list of category attributes. This pull request replaces this with a list generated from cache. The cache is built from reading view/adminhtml/ui_component/category_form.xml files, so this dynamically generated list includes all category attributes, not only those in the hard-coded list.

Fixed Issues

  1. Fixes Adding custom attribute to category doesn't show store specific value #13440 - Adding custom attribute to category doesn't show store specific value

Related Pull Requests

https://github.com/magento/partners-magento2ee/pull/267

Manual testing scenarios

See issue #13440 for reproduction steps, expected result, and actual result.

Questions or comments

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)

@m2-assistant
Copy link

m2-assistant bot commented May 13, 2020

Hi @fredden. 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 only 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). <test-build(s)> is a comma-separated list of build names. Allowed build names are Database Compare, Functional Tests CE, Functional Tests EE, Functional Tests B2B, Integration Tests, Magento Health Index, Sample Data Tests CE, Sample Data Tests EE, Sample Data Tests B2B, Static Tests, Unit Tests, WebAPI Tests.

ℹ️ 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.

@FredericMartinez
Copy link
Contributor

It works in 2.3.5-p1
Thanks @fredden

@marvinhinz
Copy link
Contributor

@magento run all tests

@thampe
Copy link

thampe commented Jul 10, 2020

This looks good, I also tested it in 2.3.5-p1.

@marvinhinz
Copy link
Contributor

@magento-engcom-team any idea why there are no build reports?

@marvinhinz
Copy link
Contributor

@magento run all tests

@sidolov sidolov added Priority: P2 A defect with this priority could have functionality issues which are not to expectations. Severity: S2 Major restrictions or short-term circumventions are required until a fix is available. Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. and removed Priority: P2 A defect with this priority could have functionality issues which are not to expectations. labels Aug 17, 2020
@lenaorobei
Copy link
Contributor

@magento run all tests

@@ -233,6 +241,7 @@ public function __construct(
$this->storeManager = $storeManager;
$this->request = $request;
$this->categoryFactory = $categoryFactory;
$this->uiConfigFactory = $uiConfigFactory;
Copy link
Contributor

Choose a reason for hiding this comment

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

To keep backward compatibility let's add nullable argument.

Copy link
Member Author

Choose a reason for hiding this comment

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

As far as I know, Magento's stance on extension is to prefer composition over inheritance. If a third party has extended this model via a preference (which is documented as "a method of last resort"), then keeping their extension up to date with changes here is a necessary cost to using such a technique. I do not see any benefit in using a nullable argument here.

My objections aside, I do not know how to create this object if not via dependency injection. (I have no experience with the Object Manager as "Magento prohibits the direct use of the ObjectManager" and any existing usages "are not tacit endorsements of using the ObjectManager directly." I understand this exists as an internal implementation detail of Magento's dependency injection system.)
How should I create this virtualType if not supplied via dependency injection?

<virtualType name="uiComponentConfigFactory" type="Magento\Framework\Config\DataInterfaceFactory">
<arguments>
<argument xsi:type="string" name="instanceName">Magento\Ui\Config\Data</argument>
</arguments>
</virtualType>

Copy link
Contributor

Choose a reason for hiding this comment

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

You are absolutely right about composition over inheritance principle. However, constructor modification is considered as a braking change. As a workaround, we recommend adding new optional parameter to the constructor at the end of the arguments list.

Please refer to the Backward compatible development guide and section about Adding a constructor parameter.

@ghost ghost assigned lenaorobei Aug 17, 2020
}

// Remove empty groups
if (empty($fieldsMap[$group])) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I believe we can remove this along with assignment in the line 674.

Copy link
Member Author

Choose a reason for hiding this comment

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

Technically we can remove this and the assignment on 674. I'd prefer to keep these however, as I feel like this method is more explicit in intent: showing clearly that empty groups are omitted on purpose.

The PHP manual also suggests that implicit array creation is discouraged. (Emphasis is mine.)

https://www.php.net/manual/en/language.types.array.php#language.types.array.syntax.modifying

If $arr doesn't exist yet, it will be created, so this is also an alternative way to create an array. This practice is however discouraged because if $arr already contains some value (e.g. string from request variable) then this value will stay in the place and [] may actually stand for string access operator. It is always better to initialize a variable by a direct assignment.

Copy link
Contributor

Choose a reason for hiding this comment

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

In this case I'd prefer creating array variable to collect needed data and if it is not empty, write this data to $fieldsMap[$group].

Copy link
Contributor

@lenaorobei lenaorobei left a comment

Choose a reason for hiding this comment

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

Please see review comments.

Looks like the fix should be applied to commerce repo. You can easily open commerce PR and link this this one through PR description.

@engcom-Foxtrot
Copy link
Contributor

@magento run all tests

@engcom-Foxtrot
Copy link
Contributor

@magento run all tests

@lenaorobei lenaorobei added Risk: medium Auto-Tests: Covered All changes in Pull Request is covered by auto-tests labels Sep 25, 2020
@engcom-Alfa
Copy link
Contributor

✔️ QA Passed

Manual testing scenario:

  1. Create new module with Setup InstallData.php
  2. Install new category attribute following Magento's current category attribute array.
    magento-bug2.txt
  3. Add view/adminhtml/ui_component/category_form.xml for above attribute
    magento-bug.txt
  4. php bin/magento setup:upgrade
  5. Set different values per scope level using store switcher

Before:
✖️ Can't see [Store View] label under attribute label.
✖️ Can't see different values per scope level (global, website, store)

2020-10-01_12-03

After:
✔️ [Store View] label under attribute label.
✔️ Able to see different values per scope level (global, website, store)

2020-10-01_12-06
On Storefront:
Peek 2020-10-01 11-33

On Admin panel:
Peek 2020-10-01 12-08

@engcom-Alfa engcom-Alfa added the QA: Added to Regression Scope Scenario was analysed and added to Regression Testing Scope label Oct 1, 2020
@engcom-Foxtrot
Copy link
Contributor

@magento run all tests

1 similar comment
@engcom-Foxtrot
Copy link
Contributor

@magento run all tests

@m2-assistant
Copy link

m2-assistant bot commented Oct 7, 2020

Hi @fredden, 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.

@fredden fredden deleted the uiComponent/category_form-hard-coded-list branch October 7, 2020 21:19
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 Component: Catalog Partner: Fisheye partners-contribution Pull Request is created by Magento Partner Priority: P1 Once P0 defects have been fixed, a defect having this priority is the next candidate for fixing. Progress: accept QA: Added to Regression Scope Scenario was analysed and added to Regression Testing Scope Release Line: 2.4 Risk: medium 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.

Adding custom attribute to category doesn't show store specific value
9 participants