From Pillow 4.2, it is forbidden to save RGBA images as JPEG
( https://github.com/python-pillow/Pillow/commit/e4d6223c944cf44c468cc65a560b94dfcf351a62 )
A crash was occurring when loading demo JPGs as
image_resize_and_sharpen() was silently changing image mode to RGBA.
Now we ensure that we return the original image mode.
We also avoid crashes when converting from PNG to JPG
Rev. 8245c1d1d8 introduced a timeout to
avoid lockup situations with wkhtmltopdf's requests on servers with low
numbers of free HTTP workers.
The initial timeout of 500ms was chosen based on average network
latency, but turned out to cause spurious disconnections on congested
networks combined with slow links.
Bumping up the timeout to 2s seems to be a better sweet spot, causing
less spurious disconnections while still recovering reasonably fast from
the wkhtmltopdf lockup situation.
See also these discussions:
- https://github.com/odoo/odoo/commit/8245c1d1d87b443701b161d8d4a42df2b4d13aec#commitcomment-22904347
- PR #12356
- Issue #2114Closes#17998
When opening the reconciliation widget, there are two queries that are done,
The first one is to find a move line that perfectly match the statement line
and is done in SQL for performance issue.
The second one is a search with a domain to find all the lines that could be used
in that reconciliation.
1) There was a mismatch between the two. The domain fetches lines that have a payment_id
while the SQL query does not. Which is inconsistent
2) In some case, we did not find a perfect match on the amount using the SQL query because
of a rounding error. Example is for amount 3,3. In python: 3,3 is represented like this
3,3000000000003 and doing a float_round of that value still returns 3,3000000000003
Since we want to match on an exact amount, using float_repr is needed to fix that error
If the website default language is not en_US, qweb fields are not
translatable in en_US (and thus can't be translated) because:
- the code expected en_US to be the default language.
- there was a error in website _dispatch
opw-746776
closes#17939
In an invoice, the modification of an invoice line triggers the complete
recomputation of the tax lines. However, it also deletes any manual
taxes that could have been set (e.g. on vendor bills).
Courtesy of @jjscarafia
Closes#17885
opw-749323
Really apply commit a9ce4ffb22 to POS orders.
Since the creation of a POS order in the backend is a feature which
nearly not used, we rewrite everything related to onchanges. To avoid
breaking the compatibility, the old onchange code is kept. As long as
the user doesn't upgrade the module it will be used instead of the new
onchange.
opw-746827
With the new client web from v9, we start the new action before to destroy the old one.
When we switch from Apps (store) to Update and vice-versa, iframe was not loaded correctly.
In case of the Apps widget, we are binding event of the new iframe during the start,
and when it is ready, we destroy the old ifram and so unbind the listener of 'message.apps'.
Using a uniq id, we ensure to bind new event, and only unbind old event during the destroy.
With the flow:
- create a contact with email address set
- click on smart button "opportunities"
When creating opportunity with the plain "create button", the opportunity gets its email_from correctly
whereas
when creating an opportunity from a kanban state's quick create, only the partner is set, and not the email_from
This commit aims at setting the email_from using either way of creating an opportunity
OPW 743698
Closes#17664
Re-enable the constraint when reconciling entries belonging to different
partners.
The constrain was not triggerd because of the triggers on line_id.
In old API it was triggered only when explicitely writing on that field.
Convert to new API instead.
Fixes#17292Closes#17600
When duplicating a quotation without template, the expiration date
was duplicated even if the expiration date was already expired.
The date order is not duplicated but set to now.
opw:744671
After rev d938ba87ae, taxes that are
included in the price are subtracted in case the tax is not applied in
an order (e.g. when the fiscal position remove the tax).
Some of the test orders did not apply any tax, and because the products
used in the test had some tax included, the above revision made the
tests fail (by subtracting the tax amount from the price).
Fixed by making the test orders more consistent wrt to taxes, applying
the taxes as would happen in the UI, then correcting the payment amounts
to include the extra tax amounts.
- Set your timezone in Brasil
- Install the Maintenance module
- Create a Maintenance Request, set the Requested Date to 2017-06-15
- Save
In the chatter, the track fields message shows a Requested Date of
2017-06-14.
This can actually happen with any date tracked. The issue comes from the
web client: it converts the date in UTC, which should of course not be
done. This only applies for a datetime, not for a date.
opw-746216
Creating and editing mass mailing in multiple language is managed with
the change 05daa15.
But currently the language the mass mailing is sent in, is the language
of the "Process Mass Mailing Queue" (root user if not changed) so all
the recipients will receive the mail in the root user language has at
the time the given batch of mails is sended.
So this is different from what someone could expect by it being
translatable. In any case the recipients list could be based on a lead,
a partner a mass mailing contact or other and a language could not be
determinable in stable (a mass mailing contact does not have a language
for example).
If the system worked, there is also a usability downside in the meaning
that someone could duplicate a mail and not check all translation and
not be aware that the mail he see is maybe not the mail that will be
received (if translations have not all been completed).
In stable to have the same behavior in any case and lessen the usability
burden of users thinking erroneously the mass mailing may be sent in
several languages depending on a not-existing heuristic, this changeset
remove the translatability of mass mailing content.
This has the following effect:
no translation editing appear,
the mass mailing is edited and sent in one and the same language,
If someone want to send a mass mailing in several language, currently in
Odoo it would then require to:
duplicate the mass mailing,
change the domains of recipients base on choosen heuristic,
edit the duplicated mass mailing in the choosen language
opw-746445
opw-746776
closes#17718
Before this the -webkit-text-security CSS property was used. This, as
the name implies, only works in webkit based browsers. Instead we can
just render the PIN code as •'s since the value of the inputBuffer is
used (not the rendered text) when checking the PIN.
Fixes#16458
Christophe Simonis