[LIS-109] PrestaShop Plugin Migration to integration-core - #71
kristinalogeecom wants to merge 13 commits into
Conversation
ISSUE: LIS-109
ISSUE: LIS-109
LIS-109
ISSUE: LIS-109
ISSUE: LIS-109
getCountryConfiguration() unsets the configurations whose country is no
longer sold in, which leaves gaps in the keys. Every caller passes the
result straight on: array_map preserves keys, so a gapped array reaches
json_encode and is serialized as an object instead of a list. A store
configured for ES, IT, FR and PT that stopped selling in IT answered
{"0":"ES","2":"FR","3":"PT"} for sellingCountries.
It reaches the general settings and banner settings of both AdminAPI and
the configuration webhook, and the Express Checkout payload, all through
getCountryConfiguration() or getCountryCodes().
ISSUE: LIS-109
ISSUE: LIS-109
ISSUE: LIS-109
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ISSUE: LIS-109
ISSUE: LIS-109
ISSUE: LIS-109
AleksandarBoljanovic
left a comment
AleksandarBoljanovic
left a comment
There was a problem hiding this comment.
Code review: two findings, both inline, both around the new getPortalUrl / consent handling in the connection flow.
| ); | ||
| $connected = $this->connectionService->connect($onboardingData->getConnections()); | ||
|
|
||
| if (!empty($connected)) { |
There was a problem hiding this comment.
The statistical-data consent is now saved only when connect() returned at least one connection. ConnectionService::connect() continues past every connection without credentials, so an onboarding submit where the merchant only toggles the consent checkbox and leaves the credential fields blank returns a SuccessfulConnectionResponse while silently persisting no consent change.
If the intent is "do not record consent for a store that never connected", that is reasonable, but the response should then not read as a success. If consent is meant to be independent of the connect outcome, the save belongs outside the if.
| return null; | ||
| } | ||
|
|
||
| $portalUrl = $this->getPortalBaseUrl(reset($connections)); |
There was a problem hiding this comment.
reset($connections) picks an arbitrary deployment. With several deployments connected - and possibly mixed live/sandbox environments, since getPortalBaseUrl() branches on isLive() - the portal link handed to the back office points at whichever connection happens to sit first in the array, not at the one the merchant just connected or is currently looking at.
Worth either selecting the connection deliberately (by deployment/environment) or documenting that the first one is authoritative here.
2 participants
What is the goal?
Extend
integration-corewith the functionality required by the new integration flow and Admin UI.The changes support:
References
How is it being implemented?
Onboarding and connection
portalUrlto onboarding and connection responses so integrations can redirect merchants to the Merchant Portal.Plugin configuration
orderIdentifierto General Settings.OrderIdentifiersProviderInterfaceso integrations can provide the order identifiers available on their platform.Solicitation
Introduced
SolicitationRequestfor the solicitation flow.Added core-level validation for:
Validation is performed before making the solicitation request.
Ineligible carts return an empty successful solicitation response instead of an error.
Added a non-throwing country-to-merchant lookup for solicitation validation.
Order management
AdminAPI::orderManagement($storeId)->updateOrder().Widget settings and webhooks
501 Not Implementedinstead of400.Opportunistic refactorings
Authorization,Proxy-Authorization,CookieandSet-Cookie.Caveats
CheckoutAPI::solicitation()->solicitFor()now accepts aSolicitationRequestinstead of aCreateOrderRequestBuilder. This is a breaking change for existing consumers and requires integrations to update their solicitation calls.OrderIdentifiersProviderInterfaceis optional, so existing integrations remain compatible if they do not implement it.Does it affect (change or update) any sensitive data?
Yes, the change reduces sensitive data exposure.
HTTP logs now mask
Authorization,Proxy-Authorization,CookieandSet-Cookieheaders. No new category of sensitive data is introduced or stored.How is it tested?
Automatic tests are executed with PHPUnit in the PHP 7.2 container.
Coverage was added or extended for:
Quality gates:
./bin/phpcs./bin/phpstan(level 6)How is it going to be deployed?
Standard deployment.
This is a Composer library. Consumers need to update the dependency to use the new functionality.