payone-gmbh / oxid-6 Goto Github PK

Hi,

with the new Payone release 1.0.9 these errors occured in the Payone unit tests using our b-6.1.x branch:

There were 7 errors:

1. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support::test_getViewId_Coverage
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_supportTest.php:70
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

2. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support::test_fcGetAdminSeperator_OldShopVersion
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_supportTest.php:83
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

3. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support::test_fcGetAdminSeperator_NewerShopVersion
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_supportTest.php:104
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

4. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support_main::test_fcpoGetVersion_Coverage
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support_main

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_support_mainTest.php:70
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

5. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support_main::test_fcpoGetMerchantId_Coverage
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support_main

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_support_mainTest.php:89
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

6. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support_main::test_fcpoGetIntegratorId_Coverage
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support_main

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_support_mainTest.php:112
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

7. Unit_fcPayOne_Application_Controllers_Admin_fcpayone_support_main::test_getViewId_Coverage
   OxidEsales\Eshop\Core\Exception\SystemComponentException: EXCEPTION_SYSTEMCOMPONENT_CLASSNOTFOUND fcpayone_support_main

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/oxideshop-ce/source/Core/UtilsObject.php:222
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/oxfunctions.php:101
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/application/controllers/admin/fcpayone_support_mainTest.php:131
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

--

There was 1 failure:

1. Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test_fcpoKlarnaIsBirthdayNeeded_Coverage
   Failed asserting that false matches expected true.

/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/source/modules/fc/fcpayone/tests/unit/fcPayOne/extend/application/controllers/fcPayonePaymentViewTest.php:1664
/srv/pool/public_html/compilation_tests_unit_EDITION_ce_label_unit/5353/vendor/oxid-esales/testing-library/library/UnitTestCase.php:149

Hallo,

wir haben mit seit dem Update auf Oxid 6 ca. einmal wöchentlich den Fall, dass eine Paypalzahlung erfolgreich durchgeführt wurde, jedoch im Anschluss im Shop keine Bestellung angelegt wurde. Dieser Fehler wird erst bemerkt, wenn sich Kunden aktiv melden und nach einer Bestellbestätigung fragen. Hier ein aktuelles Beispiel:

Transaktionslog des Moduls:

Bestellübersicht in diesem Zeitraum:

Im Exception.log gibt es in diesem Zeitfenster keinen Eintrag.

Wie kann man vorgehen, um den Fehler zu finden?

Vielen Dank!

I tried to run tests with module v1.0.7 and OXID eShop compilation v6.0.1 and got some failures:

vendor/bin/runtests
1) Unit_fcPayOne_Extend_Application_Controllers_fcPayOneOrderView::test__fcpoHandlePaypalExpressUser_RemoveAddressFromSession
OxidEsales\Eshop\Core\Exception\SystemComponentException: Function 'fcpoDoesUserAlreadyExist' does not exist or is not accessible! (Mock_fcPayOneUser_3756d52c)
2) Unit_fcPayOne_Extend_Application_Controllers_fcPayOneOrderView::test__fcpoHandlePaypalExpressUser_CreatePaypalDelAddress
OxidEsales\Eshop\Core\Exception\SystemComponentException: Function 'fcpoDoesUserAlreadyExist' does not exist or is not accessible! (Mock_fcPayOneUser_3756d52c)
3) Unit_fcPayOne_Extend_Application_Controllers_fcPayOneOrderView::test__fcpoHandlePaypalExpressUser_ThrowException
OxidEsales\Eshop\Core\Exception\SystemComponentException: Function 'fcpoDoesUserAlreadyExist' does not exist or is not accessible! (Mock_fcPayOneUser_3756d52c)
4) Unit_fcPayOne_Extend_Application_Controllers_fcPayOneOrderView::test__fcpoHandlePaypalExpressUser_CreatePaypalAddress
OxidEsales\Eshop\Core\Exception\SystemComponentException: Function 'fcpoDoesUserAlreadyExist' does not exist or is not accessible! (Mock_fcPayOneUser_3756d52c)
5) Unit_fcPayOne_Extend_Application_Controllers_fcPayOneOrderView::test__handlePayPalExpressCall_Coverage
OxidEsales\Eshop\Core\Exception\SystemComponentException: Function 'fcpoDoesUserAlreadyExist' does not exist or is not accessible! (Mock_DeliverySet_612589a8)

Tag: V1.3.2
core/fcpayone_events.php:578

Should the expected value not be char32 instead of int11? Currently, as far as I can see, it does not perform the migration because of this and the column remains an int11. This caused problems with the status.php.

Greetings,
Christoph

To whom it may concern,

Our Dev team just discovered an error in the file fcporequest.php of the oxid-6 module in version 1.0.5. The error still exists in version 1.0.8 (line 1947):

The missing return statement leads to the shop ignoring the actual score value of the customer and using the fallback score value of 100 instead. Hence customers are not able to use invoice and credit card as payment method. Since a high percentage of customers prefer invoice, this is really an issue.

Do not hesitate to contact me in case of any questions you might have on this issue. Thank you!

Best regards,

Massimiliano Siddi

Hallo,

nach dem Update auf Version 1.6.2 erscheint beim Aufruf von vendor/bin/oe-console oe:module:activate fcpayone die Fehlermeldung:

` An exception occurred while executing 'ALTER TABLE fcporefnr CHANGE OXTIMESTAMP OXTIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 'Timestamp';':

SQLSTATE[42S22]: Column not found: 1054 Unknown column 'OXTIMESTAMP' in 'fcporefnr' `

in out/blocks/fcpo_payment_select_override.tpl there is an if-else statement for choosing flow or azure templates:

[{if method_exists($oViewConf, 'getActiveTheme') && $oViewConf->getActiveTheme() == 'flow'}]
    [{assign var="sFcPoTemplatePath" value='flow'}]
[{else}]
    [{assign var="sFcPoTemplatePath" value='azure'}]
[{/if}]

The way its done, all flow child themes will get templates for azure. sincce their name is not "flow".

1. The best solution would be adding module setting and let customer pick wherever he wants flow or azure module templates. This will also work with 3rd party themes like roxive.

2. Another possible solution could be something like this:

[{if method_exists($oViewConf, 'getActiveTheme') && $oViewConf->getActiveTheme()|strpos:'flow' !== false}]
    [{assign var="sFcPoTemplatePath" value='flow'}]
[{else}]
    [{assign var="sFcPoTemplatePath" value='azure'}]
[{/if}]

This way at least all themes that contain "flow" in their names will get flow templates (since many people name their child themes something like "flow"+"shop name")

You should also apply this fix to the module for oxid v4/v5.
I also would like to mention, that there is no azure in v6 anymore and this code is actually obsolete.

cheers

Hello,

ich fürchte, dass der aktuelle Code für IP-Filterung nicht hinter einem Loadbalancer / Reverse Proxy funktioniert, obwohl das erwünscht ist.
Und zwar gibts im $_SERVER zwei Stellen mit IP Adressen:
REMOTE_ADDR würde ohne Loadbalancer die Besucher-IP haben und mit Loadbalancer dann die IP vom Loadbalancer
HTTP_X_FORWARDED_FOR bekommt hinter einem Loadbalancer die IP des Besuchers.

Die Filter-Logik für REMOTE_ADDR unterstützt wildcards, die Logik für HTTP_X_FORWARDED_FOR aber nicht.
Problematisch ist das, weil die Client IP im HTTP_X_FORWARDED_FOR ist und die Server-IP von PayOne als Widcard vorliegt (siehe config.ipwhitelist.php)

Nach meinem ersten Eindruck müsste die Logik so umgebaut werden, dass sowohl REMOTE_ADDR als auch HTTP_X_FORWARDED_FOR in ein gemeinsames array gepackt werden und von einer Filter-Funktion mit wildcard-Logik geprüft werden. Ich sehe spontan keine Notwendigkeit, zwei getrennte Whitelist Arrays für die beiden Server Variablen zu nutzen und sie auch getrennt voneinander zu prüfen.

Wir werden diese Logik für unseren Kunden umbauen und ich würde euch dann das Ergebnis als PR bereitstellen.

Viele Grüße
Marat

Tests started failing on June 7th:

1) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test__fcpoProcessValidation_BoniMoment_1
Error: Call to a member function getBasket() on null
2) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test__fcpoProcessValidation_BoniMoment_2
Error: Call to a member function getBasket() on null
3) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::tests__fcpoProcessValidation_Error
Error: Call to a member function getBasket() on null
4) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::tests__fcpoProcessValidation_Ok
Error: Call to a member function getBasket() on null
5) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test__fcpoPayolutionSaveRequestedValues_ValidBirthdate
Missing argument 2 for Mock_fcpayonepaymentview_4239915e::_fcpoSaveBirthdayData()
6) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test__fcpoExtractBirthdateFromRequest_Payolution
Missing argument 2 for fcPayOnePaymentView::_fcpoExtractBirthdateFromRequest()
7) Unit_fcPayOne_Extend_Application_Controllers_fcPayOnePaymentView::test__fcpoValidateBirthdayData_Payolution
Missing argument 2 for fcPayOnePaymentView::_fcpoValidateBirthdayData()

Hallo,

wir haben bei den Zahlungsarten Kreditkarte und Paypal die Autorisierungsmethode: Autorisierung eingestellt, der Betrag soll sofort belastet werden. Nun gibt es zwischen der Reservierung und dem Zahlungseingang regelmäßig eine große Zeitspanne (bis zu 10 min), hier beispielhaft eine Paypal-Zahlung:

2020-11-24 08:42:58 Reservierung
2020-11-24 08:48:36 Zahlungseingang

In der Zwischenzeit holt jedoch oft unsere Wawi (Roqqio) die Aufträge ab und setzt sie auf den Status "unbezahlt". Wir müssen dann manuell den Zahlungseingang buchen.

Lässt sich das Modul umstellen, so dass der Zahlungseingang schneller bzw. sofort nach Reservierung verbucht wird?

This passage in the JS code refers to a config entry which has been removed in the current version of the module.

fcpo_checktype is populated via the payment controller with the config entry sFCPOPOSCheck. The possibility to set this value has been on the admin page "PAYONE Configuration" -> "Protect" under "Address check", which has been removed from the module.

Since the setting option has been removed, the request for the address check should also be removed from the Javascript file.

Currently the config entry is empty, which results in the address check always being executed. A workaround is to manually set the config entry to "-1" to disable the check for direct debit until the problem is fixed.

The problem usually only occurs when you install the module afresh, because then the config entry sFCPOPOSCheck is not present and therefore empty. If you update the old module, the entry is already in the database if the setting was set before.

Problem: An dieser Stelle wird es nicht geprüft ob das Benutzerland oder Lieferland im Shop aktiv ist: \Order::validateDeliveryAddress

Lösung: Es soll vor Order-Abschluss im Frontend noch eine Backend-Validierung auf das Bestell-Land durchgeführt werden. Dadurch soll vermieden werden, dass mit Hilfe von Paypal Express in Länder versendet wird, die nicht im Shop freigeschaltet wurden.

Modulversion: alle (1.0.0 bis 1.1.0)

Hi,

bei der Abarbeitung eines PayOne Bezahlprozesses wird anschließend nicht die parent::finalizeOrder aufgerufen. Was dazu führt das die Verarbeitungskette von Oxid unterbrochen wird und somit andere Module die die finalizeOrder überladen nicht aufgerufen werden.

Klasse: fcPayOneOrder

Problem: Wird man im Fehlerfall (bspw. nicht ausreichendes Guthaben) vom Paymentanbieter zurück in den Shop redirected, wird keine Fehlermeldung angezeigt.

Ursache ist, dass an der Stelle, an der die Error-URL zusammengebaut wird (\fcpoRequest::_addRedirectUrls), der von OXID erwartete Error-Parameter nicht angegeben wird.
fcPayone erwartet im Template (out/blocks/fcpo_payment_errors.tpl) den Errorcode –20 und den Fehlertext.
Damit eine Fehlermeldung angezeigt wird, müssen die Parameter payerror und payerrortext an die Error-URL angehängt werden.

Modulversion: alle (1.0.0 bis 1.0.8)

Oxid Ecommerce Version 6.2.3 installs payone-gmbh / oxid-6 Version 3.0.1. Version 2.0.1 is output in the module!

Hallo,
hier ein Problem was uns aufgefallen ist:
Problem: Bezahlung mit amazonpay, wenn Rechnungsdadresse Land != Lieferadresse Land zum Bsp. Rechnungsadresse USA Lieferadresse DE -> die Lieferadresse wird nicht als oxaddress angelegt und damit nicht für die VAT Berechnung genutzt
Soll: Lieferadresse soll korrekt als oxadress angelegt werden und die VAT Berechnung anhand dieser erfolgen
Modulversion 1.2.1
Oxid 6.1.3

Hi,
we are deploying our oxid shop via bamboo and deployer and we have to execute the oe:modules:apply-configuration command to make sure we have the correct config for all our modules. Unfortunately this triggers the onDeactivate-Method of every module and so all payment-methods get deactivated because the payone module has this in its method. Is this a known problem or are there any workarounds for that?

kind regards
daniel

When running OXID eshop 6.2 compilation tests (means running tests with compilation modules installed, tests are run for shop and for each module) there are broken tests for shop and multiple modules when the PayOne module is around.
Looks like issues are caused by incorrect database default values for example

OXTIMESTAMP CHAR(32) COLLATE latin1_general_ci NOT NULL DEFAULT '',

Could you please have a look and fix this? If you need more information, feel free to contact me :)

Hi,
with the new Payone release 1.1.0 these errors occurred in the OXID eShop (6.1.x) tests using PayOne module. One of the error:
Error : Call to a member function isPayOnePaymentType() on null

To reproduce, you need to run shop tests with active module:
PARTIAL_MODULE_PATHS=fc/fcpayone ACTIVATE_ALL_MODULES=true RUN_TESTS_FOR_SHOP=true vendor/bin/runtests --filter testSetNewAmountArticleStockControlDerceasingOrderAmountToZero AllTestsUnit

Beim Abruf der Aufträge mit PAYONE-Zahlungsarten kommt die Fehlermeldung: Error on getting payone shop data: Can not find the requested plugin class.

Vorkasse-Aufträge lassen sich abrufen. Gibt es noch eine plugin-Datei für die ERP-Schnittstelle speziell für PAYONE?

Danke für die Hilfe!

Alex

Hi,

In der neuen Version 1.2.1 wird in der
extend/application/models/fcPayOneOrder::_fcpoSetPayoneUserFlagsByAuthResponse() die Methode fcpoAddPayoneUserFlag() auf dem User Object ausgeführt, diese Methode gibt es aber nicht.

Es sieht aus als wenn ein unfertiges Feature gemerged wurde.

Module version v1.0.6 is causing an exception when module is not yet active:
OxidEsales\EshopCommunity\Tests\Unit\Application\Controller\Admin\ModuleListTest::testRender OxidEsales\Eshop\Core\Exception\FileException: Requested file not found for module fcpayone (.../source/modules//payone_icon.png)
This happens because of code in: https://github.com/PAYONE-GmbH/oxid-6/blob/master/metadata.php#L23
Ideally in metadata.php should not have any logic, only configuration.

Problem: Durch den Split der aus Paypal übergebenen Adresse in \fcPayOneOrderView::_fcpoSplitAddress werden manche Straßen- und Hausnummernkombinationen nicht korrekt gesplittet.
Bei Straßennamen mit einem Leerzeichen (bspw. "Am Staudengarten 1") wird im aktuellen Code keine Hausnummer extrahiert und der gesamte String als Straße verwendet.

Modulversion: 1.2.1 (und aktuelle Version)

I ❤️ that you tend to deliver Dutch translations for the front end. However, these translations contain values in English:
https://github.com/PAYONE-GmbH/oxid-6/blob/master/application/translations/nl/fcPayOne_lang.php

Found another issue with the migrations in 1.6.2:

In this line the data from fcpo_checkdate gets copied to OXTIMESTAMP for the fcpocheckedaddresses table. But earlier in the migration this OXTIMESTAMP column never gets added. It's only in the CREATE TABLE, but if you migrate from an earlier version where the table already exists without OXTIMESTAMP it gets not created and therefore the copying e.t.c. does not work.

I had to create the column manually and deactivate and activate the module again for this to work.

Hello,

right now some merchants get a message, that they should change (rotate) their AmazonPay API Keys till 12.03.21?

When changing the keys, is the Oxid Payone Plugin still working with AmazonPay or does the merchant need to send the new keys to Payone, so Payone can put them into their configuration?

Hey everyone,

PR #46 has still not been released and unfortunately our customers are still waiting for a fix. When can we expect this fix to be released?

@fjbender
@m-siddi

In the fcpayone_events.php the OXTIMESTAMP columns are created as CHAR(32):

But the UPDATE statements change them to TIMESTAMP...

I think there is a migration missing for changing it to CHAR(32)?

btw: Why are you using CHAR(32) for this?