Odoo Changelog — 2025-05-16

Friday, May 16, 2025

56 changes · saas-18.2

Improvements(1)

Enhancements to existing features

[IMP] account_peppol: translations

PR #210313

Coresaas-18.2account_peppol

No description available.

Bug Fixes(4)

Resolved issues and error corrections

[FIX] mail: message actions mobile mailbox easier to use

PR #209689

Coresaas-18.2mail

This fixes the placement of the message action menu on mobile mailbox cards, moving the “more” button to the top-right corner. The change prevents the button from overlapping message header text when it wraps, making Inbox and History cards cleaner and easier to tap.

Original PR description

Before this commit, message actions are placed based on the type of message and its content:

- when message has bubble layout, they are placed next to the 1st line of bubble
- when message contains only attachments, they are placed next to the start of 1st attachment row
- otherwise, they are placed next to message header

The last case is a last resort which happens in non-discuss channels such as logged notes or tracking values and so on. All of them do not have "squashed" messages and the best natural placement is there in header. Message header is intended to be thin in content, so that it doesn't overpower with message content. However, message actions need to be big enough to be reached with a thumb. These considerations led to a compromise of thin header with message actions with negative margins.

This works well when message header is on a single line, but when it wraps to new line this doesn't look good because the negative margin puts it partially inside the header content.

This commit fixes the issue by changing the placement of message actions in mobile when displayed as a card, like on Inbox and History: the "..." is moved to the top-right corner of card.

This works because the card layout makes the top-right corner a natural position. This make it work like kanban views.

Note that this placement is best only in mobile: the card are short in width to make reaching message actions easy. In desktop, the message card can take almost the width of screen, so it makes it less practical than currently, close to message content.

Before
![Screenshot 2025-05-13 at 16 55 06](https://github.com/user-attachments/assets/7ce26c5d-f3a3-41fb-8a60-3736146eec7f)
After
![Screenshot 2025-05-13 at 16 54 27](https://github.com/user-attachments/assets/844e1d98-49a7-44b3-b8c9-68755385a863)

[FIX] mail: better align message actions in mobile mailbox

PR #210304

Coresaas-18.2mail

This fixes the positioning of message action controls in the mobile mailbox so they no longer overlap longer message bubbles. It also corrects right-aligned message behavior, making message cards easier to read and use on phones.

Original PR description

Follow-up of https://github.com/odoo/odoo/pull/209689

PR above put message actions in top-right corner of card. When message in mailbox was bubble and takes more than 1 line, there was overlap between bubble and this expand button.

This commit fixes it with placing expand button "..." closer to card corner. Also condition with aligned right of message were mistakenly inverted, which is also fixed by this commit.

#mobile#mailbox#message actions#layout

[FIX] account: add default string regex transaction_details

PR #209492

Coresaas-18.2account

This fix adds the same default example pattern for transaction-detail amount matching that already exists for other matching methods. It helps accounting users configure reconciliation rules more easily and reduces confusion when setting up regex-based matches.

Original PR description

A new amount type match was added for reconcile lines in the form of `from_transaction_details`.
There is a value that is proposed by default for `regex`, but not for the new one, while the matching follows the same rule. We do expect atleast a group in the regex currently, but the user has no example on which to base itself. (they currently have a traceback but it will be fixed in https://github.com/odoo/enterprise/pull/84769)

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

#reconciliation#transaction matching#configuration

[FIX] pos_blackbox_be: prevent error when printing early receipt

PR #84619

Enterprisesaas-18.2pos_blackbox_be

Restaurant staff can now print early receipts without triggering an error. This helps keep service moving smoothly and avoids interruptions during customer checkout preparation.

Original PR description

Before this commit, printing an early receipt in a restaurant would cause an error. This fix ensures that early receipts can be printed without issues.

opw-4766923

#point of sale#restaurant#receipts

Other(51)

Miscellaneous changes

[FW][FIX] point_of_sale: prevent double record creation on duplicate sync

PR #210112

Coresaas-18.2point_of_sale

Before this commit, if a paid order request was sent twice, duplicate records such as pickings or invoices could be created in the system. opw-4788967 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209958 Forward-Port-Of: odoo/odoo#209834

Original PR description

Before this commit, if a paid order request was sent twice, duplicate records such as pickings or invoices could be created in the system.

opw-4788967

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

Forward-Port-Of: odoo/odoo#209958
Forward-Port-Of: odoo/odoo#209834

[FW][FIX] mail,test_event_full: translate registration email body

PR #210195

Before this commit, message actions are placed based on the type of message and its content: - when message has bubble layout, they are placed next to the 1st line of bubble - when message contains only attachments, they are placed next to the start of 1st attachment row - otherwise, they are placed next to message header The last case is a last resort which happens in non-discuss channels such as logged notes or tracking values and so on. All of them do not have "squashed" messages and the best natural placement is there in header. Message header is intended to be thin in content, so that it doesn't overpower with message content. However, message actions need to be big enough to be reached with a thumb. These considerations led to a compromise of thin header with message actions with negative margins. This works well when message header is on a single line, but when it wraps to new line this doesn't look good because the negative margin puts it partially inside the header content. This commit fixes the issue by changing the placement of message actions in mobile when displayed as a card, like on Inbox and History: the "..." is moved to the top-right corner of card. This works because the card layout makes the top-right corner a natural position. This make it work like kanban views. Note that this placement is best only in mobile: the card are short in width to make reaching message actions easy. In desktop, the message card can take almost the width of screen, so it makes it less practical than currently, close to message content. Before ![Screenshot 2025-05-13 at 16 55 06](https://github.com/user-attachments/assets/7ce26c5d-f3a3-41fb-8a60-3736146eec7f) After ![Screenshot 2025-05-13 at 16 54 27](https://github.com/user-attachments/assets/844e1d98-49a7-44b3-b8c9-68755385a863)

Follow-up of https://github.com/odoo/odoo/pull/209689 PR above put message actions in top-right corner of card. When message in mailbox was bubble and takes more than 1 line, there was overlap between bubble and this expand button. This commit fixes it with placing expand button "..." closer to card corner. Also condition with aligned right of message were mistakenly inverted, which is also fixed by this commit.

A new amount type match was added for reconcile lines in the form of `from_transaction_details`. There is a value that is proposed by default for `regex`, but not for the new one, while the matching follows the same rule. We do expect atleast a group in the regex currently, but the user has no example on which to base itself. (they currently have a traceback but it will be fixed in https://github.com/odoo/enterprise/pull/84769) 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

Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click on New - In the 'Booked by' field, select the partner with the foreign langage - Save Current Behavior: A registration email is created but the body of the email is not translated to the language of the partner Expected Behavior: The body of the registration email should be translated in the language of the partner Cause of the issue: In order for the translation to happen inside _render_field() the variable 'equality' has to be True Link 1: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L180 Because field is equal to 'body' the value of equality is the value of self.body_has_template_value Link 2:https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L168 self.body_has_template_value is computed by checking if the 'body' attribute of self (self is an instance of mail.compose.message) is either equal to self.template_id.body_html or tools.html_sanitize(self.template_id.body_html) Link3: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L70 In this case, self.body has been computed using html_sanitize(self.template_id_html) Link4: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/odoo/fields.py#L2231 so self.body_has_template_value shoud be True The reason it's False is that when computing the value of self.body (Link4) the method html_sanitize is used with an argument (**sanitize_vals) which is not the case when comparing self.body to html_sanitize(self.template_id.body_html) (Link3) As a result self.body and html_sanitize(self.template_id.body_html) are not equal which makes self.body_has_template_value be False which makes equality be equal to False which makes the translation not happening Fix : Inside _compute_body_has_template_value() I made the method also return True if self.body is equal to html_sanitize(self.template_id.body_html,**sanitize_vals) with santize_vals having the same value as when self.body is computed opw-4349122 Forward-Port-Of: odoo/odoo#200187

[**Problem:** In POS, if a product which has two variants with the same discount is selected, in debug mode an error window appears. If not in debug mode, the selector widget appears even though it should not because it's the same discount **Steps to reproduce:** - Enable the "variants" and the "Discounts" settings - Create a new product, make it available in POS - In the "Attributes & Variants" page, add a color attribute line and give it two values - In the Point of Sale page, give it a category - Open Point of Sale/Products/Discount & loyalty, and click on New - Click on the text below "Conditional rules" on the bottom left of the screen - In the Products field select the two variants of your new product - Save - Open a shop in Point of Sale - Select your product **Current behavior:** If in debug mode an error message appears. If not in debug mode, a selector widget appears, allowing the user to choose between two times the same discount **Expected behavior:** Because it's the same discount, no window of selection (and no error window) should appear **Cause of the issue:** when computing the list of the different discounts available for a product there's no mechanism to avoid duplicates. So linkedPrograms will be a list of two identical values https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/pos_loyalty/static/src/app/services/pos_store.js#L372-L373 makeAwataible is then called with "list" containing the two objects with the same id. https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/pos_loyalty/static/src/app/services/pos_store.js#L377-L383 If not in debug mode: this will result in the creation of a SelectionPopup allowing to choose between two times the same discount If in debug mode: when __render will eventally be called, https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/web/static/lib/owl/owl.js#L3050 slotScope.this.props.list will be a list of two element with the same id, this will trigger an error thanks to this line which is added in debug mode https://github.com/odoo/odoo/blob/2e4c704d80812aabe28ae491e28c5faa4c27d693/addons/web/static/lib/owl/owl.js#L4486 opw-4703868 Forward-Port-Of: odoo/odoo#207885

### Steps to reproduce: - In the settings enable Multi-Step - Unarchive the MTO route - Create a storable product P with bom of type kit: - 1 x MTO COMP: with routes MTO and buy and set vendor - 1 X not MTO COMP: without routes - Create and confirm a sale order for 1 units of P - Update the quantity of the sale order line from 1 to 5 #### > The delivery is now for 6 units of both kit component ### Cause of the issue: Updating the quantity on the SOL will launch a call of the `_action_launch_stock_rule`.The quantity of the new procurement is then processed by these lines based on the kit data's: https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_stock/models/sale_order_line.py#L359 https://github.com/odoo/odoo/blob/65704e58fda293af727f76d5c0741b135817db99/addons/sale_mrp/models/sale_order_line.py#L153-L160 However, since one component uses the MTO route and the other does not the filter based on rules will fail since one of the component move refer to the mto rule and the other one to the delivery rule. In particular the computation will always lead to a result of 0 no matter how many are really processed because only one of the 2 moves can respect the filter. opw-4700925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209168 Forward-Port-Of: odoo/odoo#205538

Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum or SwSapien 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD invoice for `13220.00 USD` and send CFDI 4. Reconcile transaction and invoice 5. Click "Update payments" on the invoice => CRP20211 Looks like it comes from this rounding difference Rate is computed by odoo using `305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD` PAC verify the amount paid using `13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN` Solution: There is no solution by adapting the rate: - quadrum restricts the rate to 6 decimals; - rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`. So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly `round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`. In tests, both Quadrum and SwSapien seem to accept this. We don't perform the modification for Solucion Factible (the other PAC). opw-4222310 Forward-Port-Of: odoo/enterprise#85602 Forward-Port-Of: odoo/enterprise#83499

This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used. However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice. To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice. However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future). #### The fix-of-fix (this PR) To solve both those issues, here is what we do: - now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change). - if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too. task-none Forward-Port-Of: odoo/enterprise#85136

The aim of this commit is to: - avoid reporting negative amount in a 281.50 form which are rejected by the administration. - avoid reporting form with 0 value everywhere which are rejected by the administration. - avoid reporting a form with an amount < 250 EUR Context: The administration stated that we don't need to make any report that would be above 250 EUR. (art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92) https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802 Before this commit: Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax. Same for form with 0 everywhere. Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported. After this commit: Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them. task-id: None This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL. Forward-Port-Of: odoo/enterprise#85508

When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install ``Appointments`` - Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s) Traceback: ``` File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda> leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0)) File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc')) File "/home/odoo/src/odoo/odoo/_monkeypatches/pytz.py", line 129, in timezone return original_pytz_timezone(name) File "__init__.py", line 183, in timezone if zone.upper() == 'UTC': AttributeError: 'bool' object has no attribute 'upper' ``` https://github.com/odoo/enterprise/blob/2c938b66fc1b526a360f4b199a47bcc53991bcb9/appointment/wizard/appointment_manage_leaves.py#L14 When the user selects an empty timezone, tz will be False. So, It will lead to the above traceback. Forward port https://github.com/odoo/enterprise/pull/64948 was closed in master, so the issue is still present in saas-17.4 and all later versions. sentry-6537084290 Forward-Port-Of: odoo/enterprise#83363

Improvements(1)

[IMP] account_peppol: translations

Bug Fixes(4)

[FIX] mail: message actions mobile mailbox easier to use

[FIX] mail: better align message actions in mobile mailbox

[FIX] account: add default string regex transaction_details

[FIX] pos_blackbox_be: prevent error when printing early receipt

Other(51)

[FW][FIX] point_of_sale: prevent double record creation on duplicate sync

[FW][FIX] mail,test_event_full: translate registration email body

Improvements(1)

[IMP] account_peppol: translations

Bug Fixes(4)

[FIX] mail: message actions mobile mailbox easier to use

[FIX] mail: better align message actions in mobile mailbox

[FIX] account: add default string regex transaction_details

[FIX] pos_blackbox_be: prevent error when printing early receipt

Other(51)

[FW][FIX] point_of_sale: prevent double record creation on duplicate sync

[FW][FIX] mail,test_event_full: translate registration email body

[FW][FIX] mail: fix 'Message not found in viewport of Thread' tests

[FW][FIX] account: copy of account report

[FW][IMP] l10n_my_edi_extended: self billed ID

[FW][FIX] account: fix available payment methods for credit card journal

[FW][FIX] hr_work_entry{_contract}: fix work entry duration rounding

[FW][FIX] bus: has missed notification missing parameter

[FW][FIX] pos_loyalty: remove duplicate when two variants with same discount

[FW][FIX] hw_drivers: don't send devices before checkout

[FW][FIX] microsoft_calendar: new events lose owner

[FW][FIX] mrp: resolve byproduct uom widget

[FW][FIX] web_editor: fix non-deterministic tests relying on selectionchange

[FW][FIX] project: fix progress bar display in shared project

[FW][FIX] website_payment: split test to avoid iframe issue

[FW][FIX] payment_custom: show full QR code

[FW][ADD] l10n_ch: Add accounts for 13th month provision management

[FW][FIX] sms: wrong message error

[FW][FIX] test_sale_product_configurators; fix undeterminisms

[FW][FIX] account, purchase: display purchase checkbox in one-app free accounting

[FW][FIX] sale_mrp: update sol for kit product with mto components

[FW] PRHOOT 31

[FW][FIX] stock{,_dropshipping}: show all delivered SN in partner report

[FW][REM] survey: remove session tour

[FW][IMP] account: added tax type beside tax name in reconciliation model form view.

[FW][FIX] website_sale_loyalty: filter claimed rewards out of claimables

[FW][FIX] spreadsheet: export cumulated_start

[FW][IMP] l10n_ae: Added report line totals in company currency

[FW][IMP] l10n_co: support consumption taxes for Colombia by default

[FW][IMP] account_edi_ubl_cii: support AttachedDocument imports for UBL

[FW][FIX] mrp_subcontracting: move test_bom_overview

[FW][FIX] l10n_mx_edi: CRP20211 using foreign currency bank transaction

[FW][IMP] l10n_co_dian: support attached document importing

[FW][FIX] l10n_ke_hr_payroll_account: pass test if shif dependency not installed

[FW][FIX] timesheet_grid: don't focus timer on popover click

[FW][IMP] l10n_co_{edi,dian}: support ICL taxes for DIAN edi

[FW][FIX] l10n_mx_edi: Allow the invoice date to control the CFDI date

[FW][FIX] l10n_be_reports: 281.50 only report form > 250 EUR

[FW][FIX] delivery_fedex: fixed names of label stock type

[FW][FIX] test_marketing_automation, marketing_automation_whatsapp: prevent access errors when sending queued messages

[FW] PRHOOT 31

[FW][ADD] l10n_ch: Add accounts for 13th month provision management

[FW][FIX] helpdesk: search partner in specific company or no company set

[FW][FIX] l10n_es_reports: fix mod347 cash payments

[FW][FIX] documents: hide internal fields from portal users in list view

[FW][FIX] pos_self_order_iot: fix payment confirmation

[FW][FIX] appointment: prevent error while clicking on Add Closing Day(s)

[FW][FIX] account_online_synchronization: limit online acc journals domain

[FW][IMP] account_online_synchronization: zero balancing backport

[FW][FIX] spreadsheet_dashboard_sale_subscription: change displayed data

[FW][FIX] project_sale_subscription: allow Sale Manager to confirm recurring service orders