Finish Migrating "Catalog > Attributes & Features > Add new / edit attribute Group" page

[matks]

Part of Symfony migration project

Status

In order to finish the migration of this back-office page, we need to:

Todo List:

• Continue the PR Migrate attribute group edit #31502 (see below)
• The PR above misses one behavior: the ability to export the data presented by the Grid on the backoffice page. Please implement it.
• Fix broken tests
• Fix attribute group edition
• The Multistore header must also be added to the new Symfony page (if it is not already implemented). You can look at other migrated Symfony pages to see how it is built.
• The bug Uploading a texture to an attribute with a color code saved returns 404 #10596 was detected on the legacy page. We want to fix it in the Symfony page that will replace the legacy page.
• Finally, we need a last Pull Request to remove the legacy backoffice page and enable the Symfony page (see below)

About PR #31502

The PR #31502 aimed to create a new Symfony backoffice page to replace the legacy page "Catalog > Attributes & Features > Add new / edit attribute Group". The new Symfony page should follow the coding standards we have for all Symfony pages while providing the same behavior that the legacy page. It aims to create an equivalent page, but powered by Symfony and Twig :) .

Just like other Symfony pages, the application layer is Symfony + Twig, but it uses Commands and Queries to fetch and modify data. Command and Query Handlers are adapters that do rely on legacy.

What you must do for PR #31502 is to fetch it

• Verify it is correct (for you), if not please fix wrong items you have found
• Have it reviewed (and approved) by committers
• The QA will not test it: they will test the last PR (see below)

About the last PR

First Todo List items will be done by multiple PRs merged into develop. So the work of "create a new Symfony page that provides the same behavior/features as the legacy page" will be carried out BUT it is done on a Symfony page not accessible yet in the backoffice. You can browse it if you know the URL. It's like it's hidden.

In order to "finish" the job, a last PR is needed: this is the PR which removes legacy files and enables the LegacyLinks that will redirect old URLs to the new page. So the new Symfony page replaces the legacy page in the back-office. When this is done, the migration is complete.

It is possible QA will find problems when testing the last PR: behaviors that used to work with the legacy page and are not working / implemented in the Symfony page. Then you must fix them.

Please ask @MatShir if you have questions about the behavior or @matks if you have questions about the code

[marionf]

@matks Do you think we can solve this issue during the migration of this page ?

[matks]

Check-List (copied from #13989) to help verify new Symfony page is ready

Controller / template

• All controller actions are migrated and protected with @AdminSecurity annotations when eligible and @DemoRestricted annotations when eligible
• All links targeting this page are updated: either using _legacy_link or updating the code
• The new SF routes have _legacy_link and _legacy_parameters provided and explained
• Controller catches Domain Exception and translate them nicely
• Twig templates must contain relevant blocks to allow partial extension by modules
• JS being used on the page can be used as enabled extensions and use a PageMap for selectors

Conventions

• The new controller actions comply with our naming convention
• The new SF routes names and paths comply with our naming convention
• The new Twig template names comply actions with our naming convention
• Created files (controller, JS assets, CSS assets and twig views) must be in the right folder following the convention
• CSS being added must follow theme conventions

Core

• Commands and Queries only use native types but internally use VOs
• All Handlers must have an Interface

Conventions

• The created SF service names comply with our naming convention
• The created files must follow the folder convention (Domain, Core, Adapter...)

Polishing

• The legacy controller and templates files are gone
• If PR includes a new concept/mechanism, documentation must be written
• JS and CSS assets must be compiled and up-to-date
• License headers must be up-to-date
• New hooks have been added to the hooks list and the SQL updates
• Performance must be correct: page loading time, filtering/sorting/searching response time, actions response time

Testing

• Commands and Queries are tested with Behat tests
• Eligible Core classes are covered with unit tests*
• Controller is covered with survival test
• (soon) Controller is covered with E2E tests using puppeeter
• If we break E2E tests because IDs change, we must update the E2E tests

*Eligible = easy to isolate and unit tests provide values (for example testing getters/setters is useless)

[matks]

Note: if I am not wrong when the 3 issues
#10510
#10508
#33126
will be completed, the whole Tab "Catalog > Attributes & Features > Attribute Group" will have been migrated 👍