Odoo Changelog — 2024-04-12

Friday, April 12, 2024

48 changes · saas-17.2

Improvements(1)

Enhancements to existing features

[IMP] l10n_br_avatax: add documentation link in settings

Enterprisesaas-17.2l10n_br_avatax

The Brazilian Avalara tax integration settings now include a link to the newly available documentation. This helps users find setup and usage guidance directly from the configuration screen.

Original PR description

Link the brand new documentation in the settings.

This is a manual port of odoo/enterprise#48040 to 17.2, since the forward ports were created before 17.2 existed.

X-original-commit: 01c634a444b4845840832200bca3708dd91c30ac

#documentation#settings#brazil#avatax

Bug Fixes(5)

Resolved issues and error corrections

[FIX] web: lang on the url should stay after reload

PR #161683

Coresaas-17.2web

The web interface now keeps a language selected through the page URL after the browser is reloaded. This prevents users from unexpectedly returning to their default language when they refresh or continue navigating.

Original PR description

Since [1], it's possible to override the language of the user by adding the language to the query string : `lang=en_US`.
Since [2], all the key, values pairs that were on the fragment of the url, are now on the query string, and they are manipulated by the router. The information that was previously on the query string, are marked as a lockedKeys to avoid losing them when reloading the page or when a new state is push (as for example the debug key).  Unfortunately, lang was forgotten in this list, which lead to a lost of the override language when we reload the browser.

[1] : https://github.com/odoo/odoo/commit/286cc97dd45a218ce763f9f15bc34f3226e13296
[2] : https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f

#language

Other(42)

Miscellaneous changes

test

PR #161513

Coresaas-17.2unknown

This pull request appears to only revert a previous test change, with no business-facing functionality described. It is likely a housekeeping update with minimal expected impact on users or operations.

Original PR description

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#revert#test#housekeeping

[FW][FIX] account: Allow to disable the distribution of total amounts accross the lines in round_globally

Link the brand new documentation in the settings. This is a manual port of odoo/enterprise#48040 to 17.2, since the forward ports were created before 17.2 existed. X-original-commit: 01c634a444b4845840832200bca3708dd91c30ac

Since [1], it's possible to override the language of the user by adding the language to the query string : `lang=en_US`. Since [2], all the key, values pairs that were on the fragment of the url, are now on the query string, and they are manipulated by the router. The information that was previously on the query string, are marked as a lockedKeys to avoid losing them when reloading the page or when a new state is push (as for example the debug key). Unfortunately, lang was forgotten in this list, which lead to a lost of the override language when we reload the browser. [1] : https://github.com/odoo/odoo/commit/286cc97dd45a218ce763f9f15bc34f3226e13296 [2] : https://github.com/odoo/odoo/commit/c63d14a0485a553b74a8457aee158384e9ae6d3f

Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

### Context In a previous fix https://github.com/odoo/odoo/pull/83276 , the `_notify_get_reply_to_formatted_email` method was introduced to prevent edge-cases where the cpython `email` library might incorrectly fold the “Reply-To” email header. We identified an other corner case where DKIM signature verification might fail on the recipient’s end depending on the tech stack used to verify the DKIM signature vs the one used to DKIM sign it on the sending end. This might be related to how RFC5322 and RFC6376 interact with each other : In RFC5322 defines folding white spaces as follows : ``` FWS = ([*WSP CRLF] 1*WSP) / obs-FWS with obsolete FWS = 1*WSP *(CRLF 1*WSP) ``` While RFC6376 uses : `FWS = [*WSP CRLF] 1*WSP ` Based on this, it seems that for proper header content folding, the specifications expects at least one WSP (space or tab) before a CRLF. Currently when using the `email` cpython library to handle email objects, we observed that when the header value for the “Reply-To” is longer than 68 characters, it will return a folded string representation adding a linebreak after the colon. Example: `Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n` Notice that the there is no WSP between the colon character an `\r\n`. It seems that in this corner case, certain DKIM verification tech stacks (from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to” header as empty, while others correct for it (Gmail). This in returns leads to the DKIM signature verification failing. As it is impossible to test every possible combination of DKIM tech stacks in the email ecosystem and that until the `email` cpython library handles this corner case correctly, this fix tries to preformat the “Reply-To” more defensively. We also print a warning log if the `record_email` alone is longer than 68 characters (as it will not be folded), inviting the user to shorten it to prevent DKIM verification issues. ### Unit test fixing: - shortened alias name to prevent the 68 character limit from being triggered during the `test_notification_reply_to_batch` performance test (as we are not testing the 68 char here) - changed language in `test_mail_message_values_fromto_long_name` to reflect the new 68 character limit and mutted logger, as it now print a warning message ### Considerations for the future This PR only prevents the “Reply-To” from being malformed. In theory, the miss-folding could happen to any email header constructed using the `email` cpython library. In practice, the probability of the “To” and “From” being affected is low, as they usually don’t exceed a total of 78 characters as per RFC. Nevertheless if the future shows that this might be a bigger issue, one should think about: * On Odoo side: add a more robust header value formatting applied to all affected headers before the email gets sent out * On Python’s side: work with the `email` library maintainer to find a longterm solution opw-3826296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161014 Forward-Port-Of: odoo/odoo#160760

When user deletes line of journal items and tries to save invoice, a traceback appear. Steps to reproduce the error: - Create a new invoice > add 1 product > Save - Go to journal items > delete 1 line - Change currency > Save Traceback: ``` ValueError: not enough values to unpack (expected 3, got 2) File "odoo/http.py", line 2252, in __call__ response = request._serve_db() File "odoo/http.py", line 1828, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo/http.py", line 1848, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 134, in retrying result = func() File "odoo/http.py", line 1826, in _serve_ir_http return self._serve_ir_http(rule, args) File "odoo/http.py", line 1833, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2058, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 740, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 38, in call_kw return self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 34, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 458, in call_kw result = getattr(recs, name)(*args, **kwargs) File "addons/web/models/models.py", line 72, in web_save self.write(vals) File "home/odoo/src/enterprise/saas-17.1/documents_account/models/account_move.py", line 30, in write res = super().write(vals) File "addons/account/models/account_move.py", line 2669, in write self._sanitize_vals(vals) File "addons/account/models/account_move.py", line 2630, in _sanitize_vals for command, line_id, line_vals in vals['line_ids']: ``` https://github.com/odoo/odoo/blob/6768cf06138bb5c94a6c77db79ed5d802333b290/addons/account/models/account_move.py#L2422 Here, vals['line_ids'] have 2 values, so for 'line_vals' there is no value. So when user tries to save invoice, It will lead to the above traceback. sentry-5119406548 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160266

**[FIX] round_per_line: Fix payment CFDI rounding issues** - 'base' * 'tasa_o_cuota' must give 'importe' with 0.01 rounding error allowed. Suppose an invoice of 5 * 0.47 with 16% tax. Each line gives a tax amount of 0.08 so 0.40 for the whole invoice. However, 5 * 0.47 = 2.35 and 2.35 * 0.16 = 0.38 so the constraint is failing. - 'base' + 'importe' must be exactly equal to the part that is actually paid. Using the same example, we need to report 2.35 + 0.40 = 2.75 **[FIX] round_globally: Manage round globally** Before, the results given in case of round_globally was the same as round_per_line. Suppose an invoice of 5 * 0.47 with 16% tax. We were sending a tax detail of 0.47 * 0.16 ~= 0.08 for each line, so 0.40 for the whole invoice. However, in case of round globally, the total tax is 5 * 0.47 * 0.16 ~= 0.38. The invoice was incorrectly reported as an invoice of 2.75 instead of 2.73. To fix that, the base/tax amount per line are now given using 6 decimals. **[FIX] Deterministic invoices's order in payment CFDI** Before generating a payment CFDI, make sure the invoices are sorted in order to avoid a not deterministic xml. **[FIX] Rounding of TipoCambio** On the xml, the rate to switch from the invoice to payment rate is rounded to 6 decimals. By consistency, we need to use the same number of decimals during the computation to avoid the xml to be rejected. For example: With an MX company setup USD Exchange rate: - Yesterday 17.187 - Today 17.0357 Create an invoice with: - date: yesterday, quantity: 200, unit price: 7.34 USD, tax: 16% Confirm and Send the invoice Register the payment with today date Open the payment and force cfdi SAT Validation will return an error: ''' Code : CRP20204 Message : El valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la suma del resultado de multiplicar cada uno de los importes de los atributos BaseP de los impuestos trasladados registrados en el elemento TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el valor registrado en el atributo TipoCambioP de cada nodo Pago. ''' opw-3775099 **[FIX] Rounding of TotalTrasladosBaseIVA16** - Have an MX company setup - USD Exchange rate: - Yesterday 16.9912 - Today 17.068 - Create two invoices as follows: 1) date yesterday, qty 68.25, unit price 68 USD, tax 16%, total 5383.56 USD 2) date yesterday, qty 24.00, unit price 68 USD, tax 16%, total 1893.12 USD Confirm and Send the two invoices In invoices list view, select both and register payment Select 'Group Payments' Open one of the invoices, and press "Update Payments" In CFDI Tab Force cfdi for the payment Issue: Cfdi validation return an error """ Code : CRP20204 Message : El valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la suma del resultado de multiplicar cada uno de los importes de los atributos BaseP de los impuestos trasladados registrados en el elemento TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el valor registrado en el atributo TipoCambioP de cada nodo Pago. """ opw-3775099 Forward-Port-Of: odoo/enterprise#60532 Forward-Port-Of: odoo/enterprise#60025

Currently, when the company has a french localization and activates the qr code option on the pos bill, if a customer scans the qr code, he will 'inevitably' meet an error: > According to the french law, you cannot modify a point of sale order. Forbidden fields: date_order, user_id, lines, payment_ids, ... Steps to reproduce: ------------------- * Install **France - Accounting** * Switch to `FR Company` * Go to the app **Point of Sale** * Select **Configuration** > **Settings** * Enable `Use QR code on ticket` * Open a shop session * Add anything * Select/or not a customer * Select **Payment** * Select any payment method then validate * Scan the qr code on the ticket * Try filling the form and saving > Observation: Error Why the fix: ------------ We understand the confusion for french localization users to be presented with a feature which they are not able to use as intended. The Qr code feature was implemented to make it easier and quicker at the cashier but will always end up in an error, unless a client was selected and the invoice was created when validating the payment at the register. But then, it doesn't save time. Since they are not able to use the feature as intended, we decided to make it unavailable for companies with a french localization. There has been a lot of discussion about how to solve this issue. However, a lot of the ideas discussed were not doable in stable versions and this is the only solution we agreed on. opw-3704767 Forward-Port-Of: odoo/odoo#160304 Forward-Port-Of: odoo/odoo#158786

Improvements(1)

[IMP] l10n_br_avatax: add documentation link in settings

Bug Fixes(5)

[FIX] web: lang on the url should stay after reload

Other(42)

test

[FW][FIX] account: Allow to disable the distribution of total amounts accross the lines in round_globally

Improvements(1)

[IMP] l10n_br_avatax: add documentation link in settings

Bug Fixes(5)

[FIX] web: lang on the url should stay after reload

Other(42)

test

[FW][FIX] account: Allow to disable the distribution of total amounts accross the lines in round_globally

[FIX] stock: batch ir.property insert for new companies

[FIX] hr_appraisal_survey: prevent the TypeError error when uninstalling module

[FIX] helpdesk_timesheet: ensure the timesheet date is the current one

[FIX] core: use logger exception instead error to show exception details

[FW][FIX[17.0] account: wrong currency in payment terms

[FW][FIX] spreadsheet: speed-up clickable cell condition

[FW][ADD] l10n_uy: Uruguayan accounting demo

[FW][FIX] project: hide create task stage option from the project kanban

[FW][FIX] point_of_sale: optimize product packaging barcode scanning

[FW][FIX] mail: limit reply-to length to prevent miss-folding

[FW][FIX] website_sale_slides: prevent payment screen crash on pending transactions

[FW][FIX] l10n_in: fixes warning issue & allow the user to confirm the ve…

[FW][IMP] stock_account: add hook on anglosaxon dropshipping entries

[FW][FIX] web_editor, website: make added grid items always visible

[FW][FIX] account: multiple pdf msg records creation

[FW][REV] website_sale: open configurator with only no variants attributes

[FW][IMP] base: avoid infinite loops in _update_category

[FW][FIX] mail: discuss quick search with custom named chat

[FW][FIX] stock: don't print placeholders in reports

[FW][FIX] project: fixed stat button in project.project form

[FW][FIX] payment_stripe: change mobilepay code

[FW][FIX] stock: search quant by 'pick from' name

[FW][FIX] l10n_es_edi_facturae: allow unchecking Facturae on Send & Print

[FW][FIX] account: prevent valueerror after deleting journal items

[FW][FIX] mrp_subcontracting_dropshipping: don't assign twice

[FW][FIX] web_editor: prevent traceback odooEditor is undefined

[FW][FIX] web: fix gradient colorpicker traceback

[FW][FIX] web: fix binary field in settings form

[FW][FIX] stock: add active model in report context

[FW][FIX] account_edi_ubl_cii: use lang of the `move.partner_id` at export

[FW][FIX] l10n_mx_edi: Fix a lot of taxes rounding issues

[FW][FIX] l10n_be_codabox: fallback on Company ID if no Tax ID

[FW][FIX] account_reports: General Ledger: add move_name to order of shown move lines

[FW][IMP] documents: add unit tests for the document activity view

[FW][FIX] marketing automation: fix not clicked trigger

[FW][FIX] account_invoice_extract: multiple pdf msg records creation

[FW][FIX] hr_referral: fix interviewer cant see applicants

[FW][FIX] delivery_ups_rest: fix traceback if unauthorized

[FW][FIX] appointment_google_calendar: do not always generate meet link

[FW][FIX] delivery_fedex: generate return label with fedex international

[FW][FIX] social_youtube: display error for characters beyond limit

[FW][FIX] pos_restaurant_appointment: avoid crash on getMin([])

[FW][FIX] l10n_fr_pos_cert: disable qrcode for pos french users

[FW][FIX] mrp: Handle kit with BoM having qty != 1