Finish Migrating Catalog > Attributes & Features > Attribute Group > Add / edit attribute value

[MatShir]

Part of Symfony migration project

Status

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

Todo List:

• Unblock the PR Migrating attribute value page #32475 (see below)
• Now that it is not blocked anymore, continue the PR Migrating attribute value page #32475 (see below)
• 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)

Unblocking #32475

While working on PR #32475, it was found that a bug in blockwishlist module creates a problem. According to this comment, an exception is thrown when the BO user attempts to delete a Attribute value.

So we cannot migrate the page without fixing this bug in blockwishlist module!

A PR to fix blockwishlist module was submitted here PrestaShop/blockwishlist#226 BUT it could not be tested by QA. This is because when QA team attempts to verify the PR, their tests are hindered by the bug #32844 . The bug #32844 prevents the PR to be validated.

So to sum up, in order to unblock PR #32745

• Please fix bug [BlockWishList] wishlist-button-add & the list of My wishlists are not displayed on dev branch #32844 on dev branch of blockwishlist module
• Then you can ask QA to verify PR Attribute delete fix blockwishlist#226 _after you have verified the PR is up-to-date and fixes the problem happening during attribute value deletion.
• When these 2 bugs are fixed, please perform a module release
• Now you can use the latest version of blockwishlist with develop branch of the Core (please submit a PR to update the composer.lock) so PR Migrating attribute value page #32475 is unblocked 🎉

About PR #32475

The PR #32475 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 #32475 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

[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 👍

[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]

Thanks to @lartist the situation with module blockwishlist has been fixed. It does not block anymore the PR since version 3.0.1 .

Now we can continue PR #32475 : Verify it is correct (if not fix wrong items found), have it reviewed (and approved) by committers.

[WahbiPS]

Not the priority for the moment