-
Notifications
You must be signed in to change notification settings - Fork 19
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
PAYOSWXP-125: Shopware 6.6 compatibilty & BugFixes & Cypress-Tests #300
Conversation
+ & move from annotion-registration to attribute-registration
86d5a75
to
1f2b393
Compare
...nents/GenericExpressCheckout/PaymentHandler/AbstractGenericExpressCheckoutPaymentHandler.php
Show resolved
Hide resolved
+ required for SW6.6 compatibility + fixed configuration validation
invoice: b2b was never allowed (should be allowed if enabled) + add unit-tests + remove not required constraint (which was used for unzer)
+ replaced legacy sw-field component + replaced model binding + add correct content-slot for sw-page + replace component-icon (prev. icon does not exist anymore) + add missing position-identifier
6b05367
to
b351cc9
Compare
…failed test the session shared with all tests, so if the DFP has been added to the session, the next test will fail, because the DFP has been already created. with this change, we will clear the session during GET & add some additional test
…improve transition-assertiation
…ble is empty before testing behaviour
… to prevent orders without payments
frontend issues has been detected by cypress
f36d9ee
to
22ebd05
Compare
22ebd05
to
2738659
Compare
& display birthday always (prefilled)
2738659
to
2929345
Compare
ec9e9d6
to
92be8c2
Compare
this will prevent conflicts with normal payment methods
…pdate-payment-page
98c99d8
to
12702c6
Compare
} | ||
|
||
/** @var CustomerEntity|null $customer */ | ||
$customer = $this->customerRepository->search(new Criteria([$customerId]), $context)->first(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you get to this point, it would make sense to add the “defaultBillingAddress” association here, as you need it in the “getCustomerAddress” function.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point! Done.
protected function saveCustomerData(CustomerEntity $customer, RequestDataBag $dataBag, Context $context): void | ||
{ | ||
$birthday = $dataBag->get(RequestConstants::BIRTHDAY); | ||
$birthday = \is_string($birthday) ? \DateTime::createFromFormat('Y-m-d', $birthday) ?: null : null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you put the \DateTime::createFromFormat('Y-m-d', $birthday) ?: null
in brackets to make it easier to read?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
done.
<service id="PayonePayment\Components\CustomerDataPersistor\CustomerDataPersistor" autowire="true"> | ||
<argument key="$orderAddressRepository" type="service" id="order_address.repository" /> | ||
<argument key="$customerRepository" type="service" id="customer.repository" /> | ||
<argument key="$customerAddressRepository" type="service" id="customer_address.repository" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you are using “autowire” anyway, you can actually omit the repository declarations, as autowiring should also work by default for these, if the variables are named accordingly (The way you did it).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i know. But in the past Shopware does have a few problems with injecting the repositories, so i never used this in production.
my suggestion is to keep it in the backlog and refactoring this on the next SW 6.7 release.
Are you fine with that?
+ move saving to separate class to prevent saving during other request-builder calls + add saving of phonenumber into customer-address (prev. it was only saved into order-address)
d3b990f
to
e19c5b1
Compare
see ticket for more information
PLEASE DO NOT SQUASH!