-
Notifications
You must be signed in to change notification settings - Fork 213
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
[ECP-9175] Options payment/*/active are not scopable #2596
Comments
Hi @dimitriBouteille, thank you for reporting this. I have opened an internal ticket to address this issue. Once the PR introducing the fix is merged, this issue will be automatically closed. Kind regards, |
Hi @RokPopov, is there an ETA on this? Then I can determine whether I write my own fix for this or wait for the official update from Adyen. |
As a follow-up, I do believe moving towards website/store support is needed. To clarify why, let's imagine the following scenario: Merchant has 3 website scopes: United Kingdom, Germany and Austria. In Germany and Austria, Adyen is used. In United Kingdom, another local PSP is used. If I were this merchant, in the old flow (before 9.x) I would just:
Pretty straight forward: just configure the scope where it's needed and you're good to go. In the new flow, as it stands, I would need to do the following:
It's mostly this last part that's a bit irksome. In general I think it would be a cleaner solution if the recurring setup script would iterate over all the scopes, look for the payment methods config in that scope, and mutate the payment methods in that scope. This would be a win-win for everyone:
|
As another follow-up, it just so happens that the default store scope for the merchant I'm upgrading adyen does not use adyen in that store. As a result, I either need to enable the payment methods in a store where Adyen is not used (making the configuration inaccurate), or fix the recurring data script. In my case, we have the following setup:
The recurring script, which is run during every setup:upgrade, uses the scope store with a scope code of NULL and relies on the Magento scope resolver to determine the scope to read the payment/adyen_abstract/payment_methods_enabled from. This is problematic, since Magento resolves it to 1 which does not have Adyen enabled. In the scenario above, we also do not want to enable Adyen for store scope 1 because:
I think long-term it would be great if Adyen can take a look at this flow again and offer proper multi-store support. In the interim, since I don't know if Adyen wants to adopt multi-store support, I am taking the quick route here and will patch the recurring script to enforce loading the config value from the default scope. This way, we can enable adyen in the admin/default scope, but still have it turned off for store 1 in the scenario above. This is still not ideal, since we need to configure adyen for every store that exists. With proper multistore support, it would be easier if we can just configure adyen on only the stores where it's needed. Now, we still need to make sure to explicitly configure adyen and turn it off in every irrelevant store, to prevent it from falling back to default. Patch:
Edit: this patch is incomplete since Adyen will still load the payment methods based on the adyen_cc/active flags etc. from the default scope since the payment_methods_active is only used to generate all the other flags it seems... this is getting quite obnoxious to work with in multistore setups at this point. Edit 2: updated the patch to do another check before the payment methods are retrieved from the adyen backoffice. If payment methods are disabled for Adyen, retrieving them is not needed. Do note that this will cause a knockout error during checkout when adyen components are being loaded, because the component itself cannot handle there being no paymentMethods response on the object. The same would happen if no merchant account was configured. The combination of the 2 changes appear to work for me (ignoring the knockout error when the payment response is empty...) when the default store does not use Adyen. Works in both store ID 1 and a store actually using Adyen. |
@dimitriBouteille I think that PR only fixes it when saving in the admin, correct? The recurring data patch still only seems to be writing to/updating the default scope and not the store scopes. Updating public function __construct(
PaymentMethodsFactory $paymentMethodsFactory,
private readonly StoreManagerInterface $storeManager // Added this line
)
{
$this->paymentMethodsFactory = $paymentMethodsFactory;
}
public function install(ModuleDataSetupInterface $setup, ModuleContextInterface $context)
{
$setup->startSetup();
/** @var PaymentMethods $paymentMethods */
$paymentMethods = $this->paymentMethodsFactory->create();
// Toggle default scope
$paymentMethods->togglePaymentMethodsActivation();
// Toggle store scopes
foreach ($this->storeManager->getStores() as $store) {
$paymentMethods->togglePaymentMethodsActivation(null, ScopeInterface::SCOPE_STORES, $store->getId());
}
$setup->endSetup();
} Second, the line below accepts a adyen-magento2/Helper/PaymentMethods.php Line 171 in 0ca35b7
So that would need to be updated to this: $isActive = $this->configHelper->getIsPaymentMethodsActive($scopeId); |
@dimitriBouteille Hi, any update about this issue ? We still have the problem. |
Describe the bug
I think there is a problem with the
Payment methods enabled
option, in Magento this option is of type [store view]. When saving this option, thepayment/*/active
configurations are saved at the default level while this configuration is normally scopable.When I look at the
togglePaymentMethodsActivation
function, no store is specified so it is the default store that is used.adyen-magento2/Helper/PaymentMethods.php
Lines 166 to 182 in 274e191
Expected behavior
Choose from two options:
Versions
The text was updated successfully, but these errors were encountered: