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.
A name_search on attribute line would possibly ends up with a domain like:
['|', ('attribute_id', '=', 'm'), ('value_ids', '=', 'm'),
('attribute_id', '=', 'm')]
which would just search the attribute.
This is caused by calling the default name_search. This commit forgo
the default name_search when we are in this attribute line special case.
courtesy-of: @fmdl
opw-813505
closes#22619closes#22760
Name of scripts piped to `odoo shell` were `__builtin__` (`builtins` in
python3), which is not really obvious (and awful if your script must
handle python2 and python3).
Change it to `__main__`, allowing to use to common pattern
`if __name__ == '__main__':`
Before this commit, when connected as a portal user, the user was not
able to post replies to existing replies. This is because the textarea
section was marked to be displayed for connected internal users only.
This commit removes the whole group restriction. Indeed, it makes sense
(as a fix), to show the textarea section for public users too. Indeed,
the "Reply" button is already shown to public users but does not do
anything. With this commit, clicking the "Reply" button shows the
textarea section for everybody and, if the user is not connected,
redirects to the login page when posting the message. This of course
needs usability improvements in master.
Note: the problem had originally been fixed for regular answers with
commit https://github.com/odoo/odoo/commit/b81b03c82d282dc94595a9beb94444041509ef25
Note 2: both mentioned problems were originally introduced by commit
https://github.com/odoo/odoo/commit/9069d0127c176317436b67b23ae5677dd9d53de7
Closes https://github.com/odoo/odoo/issues/22648
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
note: backport of 10.0 13c326caaa
opw-807180
closes#22701
When saving a modified mass mailing, the editor will do a number of
things to improve the mail readability accross mail client.
One of those is replacing font awesome icons by image, but firefox acts
differently than other browser. On a display:none iframe, doing
.css('color') or .height() on an element returns respectively
`undefined` and 0.
This caused an error when getting the color that we could solve by
doing a fallback for firefox like this:
window.parent.getComputedStyle($font[0]).color
But to get the height() of an element, it seems we always need the
iframe displayed.
With this change, when the iframe is hidden and the browser is firefox,
the code try to display the iframe (with "visibility:hidden;height:1px")
when this part of the code happen.
opw-807180
closes#22639
In order to detect if a barcode scanner is being used, we detect the
delay between keypresses. The value is hardcoded to 55 ms. However, in
the case of a bluetooth scanner, this delay is often not enough,
resulting in an incorrect capture of the barcode.
We add the config parameter `barcode.max_time_between_keys_in_ms` which
allows the user to fine tune this delay for his hardware.
opw-806398
When using product variants, the product page shows:
- The product variant if different from the product image
- The product image
- Extra product images
The product variant image has to be switched dynamically when the user
choose another variant. This was broken with commit https://github.com/odoo/odoo/commit/f98bb2b86bb7c3ff0a549f24b31616c1539420a7
Indeed, it was switching the product image with the product image
variant instead.
This was because the variant/template order changed without switching
their classes. This commit changes their order again.
Also see opw-784737
Instead of looking for the "denied" permission, rather look for the "granted"
since there are three permissions: "default", "denied", "granted" - only
"granted" counts toward permission actually being granted
Closes#22633
- Create 2 companies A & B
- Create a product P with 2 phantom BOMs:
Component C1 for company A, with sequence = 10
Component C2 for company B, with sequence = 0
- Create a SO in company A for P, validate
The picking contains C2, while one would expect C1 since C2 is only for
company B.
opw-807640
On a production database with ~10000 products and multiple stock
locations, uunning the 'Inventory at date' tales ~50 minutes. Most of
the time is spent in the loop populating `group_lines` thanks to
multiple search queries.
We get rid of this loop by selecting the stock history lines and making
the match between these lines and the `read_group` result manually. On
the reference database, the duration falls to ~30 seconds.
Based on preliminary work by amoyaux
opw-803460
on account.payment, when changing the payment type to Internal Transfer,
the result of the onchange was erroneous as inbound and outbound methods
lack relevance in that case
After this commit, We choose to display all bank and cash journals in this case
OPW 804214
When clicking on a link in the editor, the "center" alignment button
was always marked as active whatever the real alignment of the link.
This was because it considered the alignment of the text inside the
link instead of the link's one inside its parent.