Revision 89c63096cb fixed the creation
of the taxes applied to account move lines when validating a pos session
The fix though overlooked two things:
- protection against recursivity
(nothing prevents a group of taxes to have a grand-parent as one of its children)
- the fact that when converting a group of taxes into a regular computed one,
the field children_ids is never reset
Those two caveats provoked a "max recursivity error" in python within the right conditions
This commit protects the recursive process from the two issues, and there is no traceback
OPW 816163
Having base_vat installed (but is potentially more general than this)
In the pos frontend, try to save a partner with an incorrect VAT
Before this commit, the generic and cryptic message "your internet is probably down" was displayed to the user
when a python exception occured
After this commit, we display the exception's message
OPW 807656
We should normally stick as close as possible to the version we depend
on in the official DEB packages. This in turn depends on the version of
Debian stable at the time of release - for 9.0 that would be Debian 8
(jessie) and thus Pillow 2.6.1.
However Pillow versions before 3.1.1 suffer from a few issues that could
lead to crashes of Odoo workers. The bugfixes have been backported in
the DEB packages for Pillow, so users of Debian/Ubuntu LTS versions
won't be affected if they are keeing their systems updated.
However it's worth an exception to our rule for pip users.
FWD-PORTS: skip
The emails sending is skipped during the tests.
The mecanism to determine if the server was running tests
was to check if the attribute `testing` was set for the thread.
Unfortunately, this `testing` attribute is removed/set to false after the loading/installation
of the modules is done, and phantomJS tests are ran post-installation,
and therefore the emails that were potentialy sent following an action
performed in a PhantomJS tour were not skipped.
This occurred for instance in the tour `project.tour`,
when the responsible of a task was changed,
the sending of the assignation notification email was not skipped.
In the case the machine on which the tests are ran does
not have an smtp server (or mailcatcher) running on the port 25,
this resulted in a test fail.
Previously, some screen in front was casted in Integer, others not.
This commits closes#22443
To improve in master using precision decimal, t-field, ...
But avoid to change in dom tree in stable version
* web_editor, website
This commit fixes a bug with table duplication in mailing template:
- Click on a snippet with two columns
- Duplicate it
-> the snippet is duplicated but the two columns are transformed in two
rows.
This was because there is an implemented behavior for column
duplication: if we duplicate a column which was alone on its row, we
duplicate the row instead. This code should however be triggered when
duplicating the column alone to be working, not the snippet that
contains it.
Note: this required a backport of a33ec972ab
which was fixing a non-critical "bug" for 11.0. This non-critical "bug" is
therefor fixed here too.
opw-807105
When portal user get email with portal url (like using
website_quote), it crashes because user is not logged.
For this case, we don't want to display the url with the
access token, but simply redirect it to messaging page.
The crash was about the "KeyError: 'view_type'" in
record_action dict, coming from website_quote.
opw-814647
Browsers' default alignement of <td/> is 'inherit'. Some mail clients do
not set this value properly though and even if it is explicitely set,
they do not compute the final value well.
As a fix, this commit forces the 'inherit' value on <td/> and computes
the real alignment for 'inherit' values when transcoding.
opw-813688
When the utility method `keep_query()` is used outside an httprequest
context (e.g. rendering a template from a unittest) the following
exception is throwng:
`RuntimeError: object unbound`
The above exception is caused by the method trying to retrieve
parameters from the HTTP request, even if the request object is unbownd.
This change ensures those parameters are retrieved only when exists,
making possible to use it outside the web client
Closes#18841Closes#22942
Closes opw-815322
On latest chromium (as of version 64), accessing rules of a stylesheet
is forbidden for cross-domain.
This commit catch and ignores the error when that happened.
chromium commit: https://chromium.googlesource.com/chromium/src/+/a4ebe08c91
opw-813480
opw-815860
closes#23009
Having a product on which a group of taxes apply (containing children taxes, obviously)
Make a sale
Validate the entries
Before this commit, the account_move_line created from the pos.order.line
had only the group of taxes as their tax_ids
Which is inconsistent against what account.invoice do,
and against what the generic report tax does
After this commit, we imitate what happens on invoices, and the movel line
created from the pos.order.line has the children of the group and the group as tax_ids
OPW 806089
Before this commit, user see a traceback:
(res_users.partner_id in (3,ARRA.. ...
operator does not exist: integer = integer[]
After update from initial commit
After append from commit 1bb74b7588
Now, extend to allow [1].extend([2,3])
This commit closes#22944
Courtesy of @paulius-sladkevicius for reporting
Deleting/replacing an image through summernote gave unexpected results.
As modifiying the related function may be tricky, this commit instead
wrap them to solve the specific erratic behavior: if the range is in/
matches an image, then simply remove the image and move the cursor to
its previous location.
Steps to reproduce:
* Create a sales order (SO).
* Assign a carrier.
* Don't press on "Set price" button next to carrier.
* Validate SO.
* Validate picking.
* Delivery line is added to the SO with price 0.
This is because the delivery SO line is added with the value of
picking carrier_price field, but that field hasn't been set.
If you modify on view carrier field, there's an onchange that
fills correct price, so I use that onchange method for getting
same results.
Before this commit, it would do the opposite of what it should:
When 'Do not show this dialog later' is checked, it would remove the
localStorage item instead of creating it.
When unchecked, it would create the localStorage item to prevent the dialog to
shows up again.
Now, we perform the correct behavior.
This closes#10882, closes#11550
Before this commit:
On portal (My Account > Invoices > Pay Now), a stripe payment in a normal
currency (eg: a non integer currency) would debit the amount *100.
This comes from b335ae0348 which added a workflow to handle integer
currencies but it also sent the *100 amount to /website_payment/transaction
that would create a TX with that amount instead of the normal amount.
Now, the normal amount is correctly sent to the backend, the multiplied amount
is just sent to StripeCheckout handler to correctly display the amount on the
popup after clicking on "Pay Now".
Note: the amount will be multiplied on the backend independently ecda057e11
Before this commit:
When website default lang was not en_US, the translation of fields* in the
web_editor would not be saved correctly.
Let's illustrate with fr_BE set as main lang:
The web_editor's RPC calls does not send language in the context when editing
a page (6ebcc06), but it does in translation mode.
Note that editing is always performed in the website main lang, fr_BE in this
case.
Therefore:
1. When EDITING:
The backend suppose the language is en_US as there is no lang in the
context (hardcoded everywhere).
It then write in the record itself instead of the ir.translation as it
should since fr_BE is a translation. (In Odoo, every lang is a translation,
en_US is always the main lang)
2. When TRANSLATING (in en_US):
It would also write on model as the web_editor send the language to the
backend when in translate mode. But since en_US is recognized as the main
lang (which is correct), it also writes in the model, overriding the
incorrect fr_BE writing which was also wrote on the model.
This has been fixed in 10.0 with these 2 commits:
036ccbe2955bf2
With these fixes, the lang is correctly added (by the backend) if the website
module is installed.
By ensuring the lang is correctly set, the ORM _write() function will process
the edition and translation datas as it should:
- If it receive en_US, it will write on the model
- If it receive another lang, it will write on ir.translation
This closes#10883, closes#22403
*Not the HTML/XML fields which are handled differently by the ORM/translation
Traceback because the `_get_asset` function was called by the
`theme_customize` route without the `values` argument (which is not
necessary for the feature).
Closes https://github.com/odoo/odoo/issues/22516
When we validate an order that need to be invoiced, and the customer is
not set, you have to enter a customer, but your order is finalized so
you have a traceback saying it cannot be modified when you try to set
the customer.
When the invoicing fails, we don't set the order as finalized.
Christophe Simonis