diff --git a/adr/2022_02_09_catalog_promotions_validation.md b/adr/2022_02_09_catalog_promotions_validation.md deleted file mode 100644 index 06ec7bd443..0000000000 --- a/adr/2022_02_09_catalog_promotions_validation.md +++ /dev/null @@ -1,66 +0,0 @@ -# Catalog promotions validation - -* Status: accepted -* Date: 2022-02-09 - -## Context and Problem Statement - -Catalog Promotions, as the new feature in Sylius 1.11, is developed in API-first manner, but of course provides -UI functionality as well. The challenge, that we faced during the implementation was the validation, and either it should -be unified for API and UI or separated. - -## Decision Drivers - -Catalog Promotions' validation should: -* be easy to customize and extend -* work on both API and UI -* validate both business scenarios and syntactical correctness - -## Considered Options - -### Unified validation in custom validators - -This is the first approach to validation we had. The concept was, to have -[custom validator for each action and scope](https://github.com/Sylius/Sylius/blob/b5458fa31aadaf699e39b0cc106d5efd25144823/src/Sylius/Bundle/CoreBundle/Validator/CatalogPromotionAction/FixedDiscountActionValidator.php). -The correct validation is chosen based on the key provided in `sylius.catalog_promotion.action_validator` tag. These custom -validators should contain both business and syntactical validation (as the latter is not configured anywhere else). - -* Good, because custom validators are unified for API and UI, which results in the lack of duplications -* Bad, because business and syntactical validation is mixed, even though these are different type of validations -* Bad, because it resulted in some problems in validation messages display (Catalog Promotions' forms are quite complicated) - -### Unified business validation and separated syntactical validation - -Variation of the previous option, which still uses custom validators but only for business (or functional) validation. -Syntactical validation is delivered separately for UI and API. - -* Good, because syntactical and business validation is separated, as it should be -* Good, because UI validation on forms is less problematic still being extendable and customizable -* Semi-bad, because it results in _apparent_ duplication of logic -* Bad, because there is no easy way to syntactically validate requests in ApiPlatform, so it needs to be done in validators anyway - -## Decision Outcome - -Chosen option: **"Unified business validation and separated syntactical validation"** - -Syntactical and functional validation are two different types of validation. They should be separated, especially as they -can be approached differently (from the technical point of view) regarding the interface used (UI or API). Moreover, this -separation gives us better control over how requests/forms are validated (e.g. some values passed in forms does not have -to be validated in Sylius, as they're already protected in used Symfony types). Output of this decisions results in following -structure of validators: - -* `src/Sylius/Bundle/PromotionBundle/Validator/CatalogPromotionAction` - base business validation of catalog promotion actions -not related to the concepts from other bundles (currently empty, only interface) -* `src/Sylius/Bundle/CoreBundle/Validator/CatalogPromotionAction` - business validation of catalog promotion actions related -to the concepts from other bundles (e.g. product variants) -* `src/Sylius/Bundle/CoreBundle/Validator/CatalogPromotionScope` - business validation of catalog promotion scopes related -to the concepts from other bundles (e.g. taxons) -* `src/Sylius/Bundle/ApiBundle/Validator/CatalogPromotion` - syntactical validation of API requests; validators here usually -decorate validators from the **CoreBundle** - -Syntactical validation of forms data shall be done on each specific form (e.g. those from `src/Sylius/Bundle/CoreBundle/Form/Type/CatalogPromotionScope`). - -## References - -* [1st approach](https://github.com/Sylius/Sylius/pull/13174) -* [Chosen approach](https://github.com/Sylius/Sylius/pull/13620) diff --git a/features/admin/user/managing_users/deleting_account.feature b/features/admin/user/managing_users/deleting_account.feature index d2fda525ff..91dd969ed9 100644 --- a/features/admin/user/managing_users/deleting_account.feature +++ b/features/admin/user/managing_users/deleting_account.feature @@ -9,12 +9,19 @@ Feature: Deleting the customer account And there is a user "theodore@example.com" identified by "pswd" And I am logged in as an administrator - @api @ui + @api @no-ui Scenario: Deleting account should not delete customer details When I delete the account of "theodore@example.com" user Then the user account should be deleted But the customer with this email should still exist + @no-api @ui + Scenario: Deleting account should not delete customer details + When I delete the account of "theodore@example.com" user + Then I should be notified that it has been successfully deleted + And the customer should have no account + But the customer with this email should still exist + @api @ui Scenario: A customer with no user cannot be deleted Given the account of "theodore@example.com" was deleted diff --git a/src/Sylius/Behat/Context/Ui/UserContext.php b/src/Sylius/Behat/Context/Ui/UserContext.php index 27c6d0fe5c..10fa8a4fde 100644 --- a/src/Sylius/Behat/Context/Ui/UserContext.php +++ b/src/Sylius/Behat/Context/Ui/UserContext.php @@ -54,12 +54,11 @@ final class UserContext implements Context } /** - * @Then the user account should be deleted + * @Then the customer should have no account */ - public function accountShouldBeDeleted() + public function theCustomerShouldHaveNoAccount(): void { $deletedUser = $this->sharedStorage->get('deleted_user'); - $this->customerShowPage->open(['id' => $deletedUser->getCustomer()->getId()]); Assert::false($this->customerShowPage->hasAccount()); diff --git a/src/Sylius/Bundle/AdminBundle/templates/customer/show/content/header/title_block/actions/delete.html.twig b/src/Sylius/Bundle/AdminBundle/templates/customer/show/content/header/title_block/actions/delete.html.twig index b148c1696b..9ef1320117 100644 --- a/src/Sylius/Bundle/AdminBundle/templates/customer/show/content/header/title_block/actions/delete.html.twig +++ b/src/Sylius/Bundle/AdminBundle/templates/customer/show/content/header/title_block/actions/delete.html.twig @@ -1,7 +1,8 @@ -{% set user = hookable_metadata.context.resource.user %} +{% set customer = hookable_metadata.context.resource %} +{% set user = customer.user %} {% if user != null %} -
+