Thursday, June 19, 2025
25 changes · 18.0
Enhancements to existing features
The base module now shares common XML-RPC request and error handling in one helper instead of duplicating it across two entry points. This is an internal cleanup that should make future maintenance easier without changing user-facing behavior.
Original PR description
Extract shared XML-RPC logic into `_xmlrpc_common`, removing duplicate try/except. **Description of the issue/feature this PR addresses:** Addresses #214536 by centralizing the duplicated error handling code in the xmlrpc controllers. **Current behavior before PR:** Both `xmlrpc_1` and `xmlrpc_2` each contain an identical try/except around the call to `_xmlrpc`, leading to code duplication. **Desired behavior after PR is merged:** Introduce a private helper `_xmlrpc_common` that handles request checking and exception mapping for both routes, keeping the public methods minimal. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Italian Libro Giornale PDF report has been made easier to read with clearer grouping, alternating background colors, and less repeated information. Journal entry numbers and dates now take up less space, making the report cleaner for review and record keeping.
Original PR description
Changes include: - Better background color alternation for each journal entry. - Journal Entry number is now shown only once, and in bold. - Moved the date into the same column as the Journal Entry number to save space. task-4844519
Resolved issues and error corrections
Fixes an issue where merging CRM leads could fail if older lead records had no priority value. This helps sales teams merge historical or incomplete lead data without interruptions.
Original PR description
The field priority is not required (even if it has a default) so it is possible to have False instead of a str.
Traceback occures when merging leads that contains historical data.
```
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1501, in _merge_opportunity
merged_data = opportunities._merge_data(self._merge_get_fields())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1457, in _merge_data
data[field_name] = fcallable(field_name, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-18.3/addons/crm/models/crm_lead.py", line 1555, in <lambda>
'priority': lambda fname, leads: max(leads.mapped('priority')) if leads else False,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '>' not supported between instances of 'str' and 'bool'
```Miscellaneous changes
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
Original PR description
Creating a post using default values in context was bypassing the karma check when adding link or image. This no-so-sexy solution just ensure that whatever the way the post is created (using or not default values in context), the check is properly executed. Task-4114387 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197325
This fix prevents the messaging interface from crashing in rare cases where a chat bubble appears but its related conversation is temporarily unavailable or deleted. Users should experience a smoother, more reliable chat experience while the system waits for data to load or recognizes that the conversation no longer exists.
Original PR description
There are some rare cases there's a chat bubble but no thread, e.g. when the thread is deleted and/or data hasn't be fetched (yet). These cases should assume no thread for a short time instead of following crash: ``` TypeError: Cannot read properties of undefined (reading 'importantCounter') ```
This fix updates an internal HTML editor test so it waits properly for toolbar popovers before checking results. It reduces random test failures, helping keep development and release validation more dependable without changing user-facing behavior.
Original PR description
The expect assertion does not wait, and waiting one animation frame is not enough for popovers, like the toolbar, as explained in [1]. [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140
This fixes an issue in the Mail composer where clicking Save or Cancel while editing a message could unexpectedly move the page. Users can now finish or discard edits without losing their place, making message updates feel smoother and less disruptive.
Original PR description
**Current behavior before PR:** Clicking "Cancel" or "Save" in the composer would unintentionally cause the page to scroll. **Desired behavior after PR is merged:** This default behavior is now prevented in `onClickCancelOrSaveEditText`. **task**-[4826935](https://www.odoo.com/odoo/my-tasks/4826935) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Sales Projects where the project display used the wrong view type after a recent change. Users should again see the expected list-style view, reducing confusion when working with projects linked to sales.
Original PR description
opw-4865213 Caused-by: https://github.com/odoo/odoo/pull/212680
Video options such as autoplay and loop now appear as proper on/off switches in the editor, even when the website app is not installed. This keeps the video settings popup consistent and easier to use across setups.
Original PR description
Description of the issue this PR addresses: - The video settings popup has toggle options like autoplay and loop. These need styles from the website module to look like switches. Without that module, they show as checkboxes. Current behavior before PR: - When the website module is not installed, Toggle options look like checkboxes instead of switches. Desired behavior after PR is merged: - Basic switch styles are added directly in the html_editor module. Toggles now look correct even without the website module. task-4865400 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A faulty test setting was removed from the Italian e-invoicing website sale module. This helps the automated checkout tests run correctly, reducing false build failures without changing customer-facing behavior.
Original PR description
steps to reproduce : 1. Install l10n_it_edi_website_sale 2. run the test `test_public_user_codice_fiscale` remove the unknown key `test` from the tour build_error-223784
This change fixes a flaky internal test in the web module that could fail unpredictably. It simplifies the test setup, making automated checks more stable without changing customer-facing behavior.
Original PR description
This commit fixes a race condition in one of Hoot's internal tests. The fix simplifies the failing test since the previous manipulations were redundant and fragile. runbot [223471](https://runbot.odoo.com/odoo/runbot.build.error/223471) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from accidentally editing purchase and vendor bill matching records that are only meant for viewing. It avoids a save error in the Purchase Matching screen, making the vendor bill workflow more reliable.
Original PR description
Currently, an error is produced when attempting to edit fields in the **Purchase Line and Vendor Bill line matching view** model. **Steps to reproduce:** - Install the `purchase` module. - Open a Vendor Bill form and click the "Purchase Matching" button. - In the list view, change the **Vendor** field of any record. - Attempt to save. **Error:** ``` UndefinedTable relation "purchase_bill_line_match" does not exist LINE 1: UPDATE "purchase_bill_line_match" ``` Here, the `purchase.bill.line.match` model is defined with `_auto = False`, meaning it is a non-storable model, does not have a corresponding database table, and therefore cannot be updated directly. [1] - https://github.com/odoo/odoo/blob/5977da2c93d522ece984d2fa8a31624f4b612eca/addons/purchase/models/purchase_bill_line_match.py#L10-L12 This commit makes fields read-only in the model, avoiding unintended write attempts on a non-storable view model. Sentry-6629713332
This fix allows records that track HTML content history to be updated in batches without failing. It improves reliability for users and administrators when multiple versioned content records are changed at once.
Original PR description
Allow batch write on model using the `HtmlFieldHistory` mixin. task-4852381 task-4731389 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Documents app now automatically configures the Internal folder with the expected email alias, matching earlier behavior on SaaS. The Sign integration also avoids errors when that folder was removed before installation, making setup more reliable.
Original PR description
As in earlier versions, add an alias to the Internal folder so that it is configured out of the box on Saas. In sign, we make sure to not try and embed an action on the Internal folder if it was already deleted before the bridge is installed. Task-4690653
The duplicate transaction search in bank accounting now works even when the Starting Date field is left empty. If no date is entered, the system uses today's date instead, avoiding an error that could interrupt accounting users.
Original PR description
Currently, an error occurs when finding duplicate transactions in the bank. Steps to Reproduce: - Install the `accountant` module. - In `Accounting Dashboard`, click on `Bank`. - In Actions, click `Find Duplicate Transactions`. - Clear the `Starting Date` field and click save. `TypeError: unsupported operand type(s) for -: 'bool' and 'relativedelta'` This error occurs when the system attempts to find duplicate transactions without a Starting Date. When finding duplicate transactions, it tries to calculate the `prior_date` using `date_from - relativedelta(months=3)` [1]. However, since `date_from` is `False`, this raises an error. [1] https://github.com/odoo/enterprise/blob/acdba5ecf89ee8920f82e07e16fac2a0f9659b12/account_online_synchronization/models/account_journal.py#L314 This commit ensures that if the Starting Date is empty when finding duplicate transactions, it uses today’s date as the Starting Date. sentry-6653835511
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better ali
Original PR description
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better aligned with official terminology, improving usability and compliance with Romanian accounting norms. The updated translations are based on the official ANAF reference: [SAF-T RO Schema Definition Codes v4.1.6](https://static.anaf.ro/static/10/Anaf/Informatii_R/SAF_T_Ro_SchemaDefinitionCodes_v4_1_6_final_1712021.xlsx) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212477
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Becaus
Original PR description
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale",…
Before this commit, when using discuss call, using some usb camera would lead to wrong camera settings: ``` aspectRatio: 1.7777777777777777 frameRate: 20, height: 360, resizeMode: "crop-and-scale", width: 640, ``` This happens because of the camera config constraints that are not well understood by some usb cameras, such as `max` for width and height. Another problem is that `frameRate` was set to 30 but a camera can stream 30.0003 frames per seconds which is slightly higher. Because of the 30 value, it forces camera to stream a much lower framerate. Also somehow the camera panics and crop the content when this is not wanted. This commit fixes the issue by simplifying constraints to only asking for explicit width. This is well understood by many cameras and it just works. Framerate is managed by camera and bandwidth constraints, aspect-ratio has no reason to be limited by constraints and instead the source decides and call view managed the layout like it does now. With the same usb camera that give the results before, with the new contraints this become: ``` aspectRatio: 1.7777777777777777 frameRate: 30.000030517578125 height: 720 resizeMode: "none" width: 1280 ``` Forward-Port-Of: odoo/odoo#214886
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214706
Original PR description
Before master, this bug is mostly hidden since no WebP files are used by default. However, an upcoming PR targeting master converts all website images to WebP (https://github.com/odoo/odoo/pull/168862), revealing warnings in the server logs due to `binary_to_image` crashing on WebP inputs. This patch avoids the crash by explicitly handling WebP files with `get_webp_size()`. Forward-Port-Of: odoo/odoo#214706
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy
Original PR description
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db.…
Follow up of 1c17cb5a27483bb41b1e5ed820bc771a7337ec6d. It is OK to write raw bytes in a Binary attachment=False field. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the begining. Those crazy people even use silly base64 libraries to encode their bytes, e.g. `base64.encodebytes` which is a Email MIME utility: it adds `\r\n` every 76th character because of the folding requirements in email headers. So those bytes are "technically" not base64 (as far as `validate=True` is concerned) but we still must decode them. CRAZY. I'm looking at you `base.language.export.data`. Forward-Port-Of: odoo/odoo#214758
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of
Original PR description
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025).…
When grouping by week/days in a pivot, some issues can be seen for dates which week is between two years (for instance 12/30/2024 is both part of the last week of 2024 and the first week of 2025). Currently, such a date is assigned to week 1 of 2024 in a spreadsheet pivot, which is false and also messes up the group by of the first week of 2024. Technically, it's an issue with the date formatting "WW/YYYY" because the two parts are decorellated. Following the ISO calendar rules, the year of the date is obviously 2024 but the week of 12/30/2024 is 1 only because we consider it part of 2025. Since both parts of the information are gathered independently, we end up with this misleading formatted value. Note: the bug was fixed following a refactoring of the date handling but we keep the tests to ensure that there are no future regressions. Task-4853825 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 Forward-Port-Of: odoo/odoo#213698 Forward-Port-Of: odoo/odoo#213302
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,7747
Original PR description
This commit fixes the `test_postcommit` that fails in a non deterministic fashion. This test ensures bus notifications created in the post commit hook result in only one batch. To do so, the test listens on the connection with a selector. However, the loop condition is incorrect and exits after the first select timeout. As a result, if the test takes more than 5 seconds, it fails. This commit fixes the loop condition to continue until the stop event is set. runbot-116746,161035,223589,77470 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 Forward-Port-Of: odoo/odoo#214737
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 Description of the issue/feature this PR addresses: Current behavior bef
Original PR description
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 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 Forward-Port-Of: odoo/odoo#214729
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will d
Original PR description
Description of the issue/feature this PR addresses: The invoice date was printed as l10n_sa_confirmation_date on the report, causing confusion for users issuing backdated invoices. Additionally, the issue date was being converted to the partner's timezone, leading to inconsistencies. Current behavior before PR: The invoice date appears as l10n_sa_confirmation_date on the report. The issue date is affected by the partner's timezone. Desired behavior after PR is merged: The report will display both the standard invoice date and l10n_sa_confirmation_date separately for clarity. The issue date will always be passed in SA timezone to the report to ensure consistency, regardless of the partner's country. task-4508551 Forward-Port-Of: odoo/odoo#211992 Forward-Port-Of: odoo/odoo#200888
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The ide
Original PR description
Prior to this commit, when validating a Scrap Order for a product with insuficient quantity, a wizard was shown to confirm the order as you would end up with a negative quantity in your warehouse. However, the view did not properly displayed quant_ids which allows seeing the current quantity for this product on the current warehouse as this compute field was not triggered during the first onchange call. When confirming the popup, the quant_ids could barely be seen before closing. The idea is to make so that quand_ids can be seen as expected before any confirmation/cancelation. Forward-Port-Of: odoo/odoo#211152
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and tha
Original PR description
Since #82896 reconciling bank statement line that has a partner with company_id set to a branch company leads to removing the partner from the statement line when validating the reconciliation. Steps: - Create a branch company and select it. - Create a contact with company_id == the branch company. - Create and confirm an invoice with that contact as partner. - Go back to accounting dashboard, and open bank reconciliation widget. - Create a new transaction with the invoice amount and that partner. - Select it, and select the invoice we created, and click on Validate. - Notice that the partner is not set (removed) from the transaction. Fix: Add another condition to check if the statement line company matches the partner company before trying to unset the partner if its company isn't a root company. opw-4809740 Forward-Port-Of: odoo/enterprise#87440