When refunding an invoice with the option: "Cancel: create refund and reconcile",
it raised a warning: "You are trying to reconcile some entries that are already reconciled!"
because in some cases the refund is linked to several entries which match the same
account of the invoice. So it tried to reconcile several times the same entries.
opw:765673
As of P3 socket.error is replaced by IOError and the underlying error
code must be accessed with `.errno `. This also worked in P2, so simply
use that all the time.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
- jcconv is not P3-ready and is only optional, for use on the POSBox
firmware for Japanese charset support in some receipt printers
(The POSBox firmware is still based on Odoo 8 + PY2 at this time)
- wsgiref is built-in since Python 2.5, and the one on pypi does not work
on Python 3.2+
Merge wizard contained dead code with references to an unused lib for
validating emails. Removing everything is easier.
+ remove unnecessary pycompat wrapping for safe use of dict.items()
No formal decision there, and the stdlib API seems like a PITA as it's
based around native strings, not bytes and not text.
* try to use cross-model API instead of random encode/decode
* unicode all the mail_template things
* formataddr *requires* a text tuple now
In P2, formataddr((False, False)) "worked" (generated "False
<False>"), in P3 it will fail and blow up.
* attachments are quite definitely bytes
* remove try_coerce_ascii because it's garbage
XMLRPC dumps returns text rather than bytes (for reasons unknown),
which does not suit Werkzeug's WSGI server, we need to encode the
body.
For simplicity and future-proofiness, return Werkzeug responses
instead, Werkzeug takes care of encoding text and passing bytes
through.
Otherwise when the subquery is somehow injected in the parent
query (didn't find where but...) it's b-prefixed and treated as a
binary rather than a sub-query somehow, which fails.
* IrValues.value should be a binary field, since pickle encodes
objects to bytes
* Which means the "action" string must be encoded before storage and
decoded before use
* Remove complete garbage mess of random encodings during XML
conversion, this probably still requires serious thinking and fixing
but it seems to run for now (yay)
* unichr -> pycompat (builtin removed from Python 3, ``chr`` has
become unicode-aware)
* Psycopg2 bytea values (binary fields) are returned as memoryviews in
P3 but buffers in P2
* Both bytes and (text) strings are conventionally iterable in
P3 (they have a __iter__ method), so fix up the exclusion pattern
for flatten
* remove references to basestring & unicode (use relevant pycompat
helpers)
* remove some str calls (either entirely or replaced by relevant
helper, either text or native)
* use better API to avoid unnecessary conversions
* remove some XML declarations in views
* StringIO removed from stdlib, replace with io
* try to correctly handle BytesIO/StringIO (one is for bytes the other
is for text)
* fix base64: Python 3 removed bytes-encoding and bytes-bytes
codecs (via #encode) so replace all calls to str.encode('base64'),
also b64encode is a bytes->bytes conversion so attempt to properly
handle that
issue #8530
Goffin Simon