- 09 May, 2024 40 commits
-
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
Because the librairies used here were never ported to python3. Notable changes: - ERP5Site_createGoogleUserToOAuth is dropped - internal API changed radically, so customizations made by overriding scripts are broken. - the core logic is now implemented in a connector class (still in portal_oauth for simplicity, but it would be simpler to move it to portal_web_services) No changes required in the google console, the redirect uri is still ERP5Site_receiveGoogleCallback
-
Carlos Ramos Carreño authored
-
Carlos Ramos Carreño authored
-
Carlos Ramos Carreño authored
The `details` part of the output of functional test cases was being wrongly converted to an unicode string in Python 2. This caused problems when the output was sent to a file object not supporting non-ASCII code points. This commit fixes that behaviour.
-
Carlos Ramos Carreño authored
-
Carlos Ramos Carreño authored
-
Carlos Ramos Carreño authored
Some tests were added to check warnings, which were not working in Python 2 because the warning message was shown just once. This is fixed by adding a `warnings.simplefilter("always")` inside the `catch_warnings` context manager, as recommended in https://docs.python.org/3/library/warnings.html#testing-warnings . Note that the previous filter is restored on leaving the context manager.
-
Carlos Ramos Carreño authored
-
Carlos Ramos Carreño authored
Instead of using encode/decode is it better to use str2bytes and bytes2str, so that the types in Python 2 are unchanged. More important, this prevents the double encoding of bytes, which causes problems when they have non-ASCII data encoded.
-
Carlos Ramos Carreño authored
Errors were being raised for returning `None` in Python 2 (due to a missing else branch) and for re-encoding bytes in Python 2. I changed the code to use str2bytes in the cases where bytes are expected.
-
Carlos Ramos Carreño authored
An unicode encoding error was being raised in test_AccountingTransaction_getListBoxColumnList_item_column in Python 2, when the `html` variable was being passed to the `StringIO` constructor. The error was only reproducible when running the tests in the CLI. The problem was that we were using cStringIO module in Python 2, and the string فارسی (farsi) appears in the HTML (probably inside a language picker). cStringIO cannot parse unicode characters that are non-ASCII. The solution is to use "six.StringIO", which uses the (slower, but unicode-compatible) StringIO module in Python 2.
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
( I'm wondering if we need this patch at all on py3 )
-
Jérome Perrin authored
__getitem__ was missing causing unsubscriptable-object on BTrees
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Kazuhiko Shiozaki authored
-
Kazuhiko Shiozaki authored
so that Tester methods will have some __roles__ as Getter.
-
Kazuhiko Shiozaki authored
because str(float) result is different between py2/py3. * py2 >>> str(-0.8999999999999999) '-0.9' * py3 >>> str(-0.8999999999999999) '-0.8999999999999999'
-
Kazuhiko Shiozaki authored
with ROUND_DOWN, we have a different behaviour between py2/py3, that caused failures in erp5_simplified_invoicing:testTradeModelLine. Here is what happened in _round(1.9999999999999998) in bt5/erp5_simulation/DocumentTemplateItem/portal_components/document.erp5.FloatEquivalenceTester.py * py2 decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN') => Decimal('2.000000') (because str(1.9999999999999998) is '2.0') * py3 decimal.Decimal(str(1.9999999999999998)).quantize(decimal.Decimal('0.000001'), 'ROUND_DOWN') => Decimal('1.999999') (because str(1.9999999999999998) is '1.9999999999999998') But ROUND_DOWN result of 1.9999999999999998 with 0.000001 precision should be 1.999999 thus py2 behaviour is wrong.
-
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-
Jérome Perrin authored
-