Friday, October 3, 2025
21 changes · saas-18.3
Resolved issues and error corrections
The Ask the Community button now opens the correct forum page for a helpdesk team instead of showing a page-not-found error. This helps customers and support users reach the community forum smoothly when forum support is enabled.
Original PR description
Scenario:
- create a helpdesk team
- enable community forum on it
- go to the team and click on "Ask the community"
Result: 404 error, this page does not exist
Cause: we are using helpdesk.team ID in route needing a forum.forum ID
Fix: uses /helpdesk/{team ID}/forums route instead of /forum/{team ID}
opw-5027193
Forward-Port-Of: odoo/enterprise#96026This change adds extra diagnostic logging to an internal bus notification test that has been failing unpredictably. It helps developers understand and resolve the intermittent test issue without changing business functionality.
Original PR description
The `test_postcommit` test ensures that the creation of several bus records result in a single postgres notify after commit. This test have been failing in a non deterministic fashion for some time. Theorical fixes have been try, but fails still persist. This commit adds some logs to this test to better understand what's happening. runbot-232798 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#228996
This removes an unnecessary database rule from Odoo's mail discussion channels. The change helps prevent failures when creating or restoring future databases on PostgreSQL 18, without changing how users interact with the mail app.
Original PR description
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful. Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1],…
The field is `required=True`, which automatically sets it `NOT NULL` (if possible). The constraint does not do anything useful.
Furthermore, pg18 promoted `NOT NULL` to "real" named constraints[1], and the constraint was created following the pattern pg uses, so trying to migrate a database to pg18 (either upgrading a cluster from 17 to 18 or restoring a db on a pg18) the restoration fails with
duplicate key value violates unique constraint "pg_constraint_conrelid_contypid_conname_index"
The easiest fix is to delete the constraint in the upstream DB if possible (I didn't find a way to filter out constraints from pg_dump or pg_restore, though it should be possible to filter it out from a "plain" dump by hand).
AFAIK Odoo does not generally drop constraints so I don't think this will fix existing databases, but it at least makes future databases compatible with pg18.
[1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a379061a22a8fdf421e1a457cc6af8503def6252
Forward-Port-Of: odoo/odoo#229539
Forward-Port-Of: odoo/odoo#229274Website pricelist snippets now keep the correct spacing and text size when descriptions are regenerated in the page builder. This prevents product descriptions from appearing too large or too close to titles, keeping website layouts polished and consistent.
Original PR description
New description paragraphs generated by the builder for the "pricelist" snippets were missing two expected classes. - "mt-2" was never applied, so all pricelist variants lacked the vertical spacing below product titles. - The boxed and cafe snippets also needed the `o_small` class to keep their text size consistent. Steps to see the missing "o_small": 1. Drop an "s_pricelist_boxed" or "Pricelist Cafe" snippet on a page. 2. Use Backspace to delete the text already present in one of the descriptions. 3. Toggle the "Descriptions" option off and on; the regenerated paragraph appears larger than expected because `o_small` is absent. task-5117864 Forward-Port-Of: odoo/odoo#229464
This update corrects an automated test step for the bank reconciliation interface so it waits for the right screen element. This helps prevent false test failures and improves confidence that the accounting workflow remains stable.
Original PR description
The step checks the non presence of `o_bank_rec_quick_create`. But this element does not exist, as it should be `o_bank_reconciliation_quick_create`. This causes the tour to sometimes fail as we click on unfold before the interface updates from the creation of the line. runbot-error-230727
Point of Sale preparation screens now display any free-text custom attribute entered for a product, matching what already appears on receipts. This helps staff see complete order details and reduces the risk of preparing items incorrectly.
Original PR description
Steps to reproduce: ------------------- 1. Create a PoS product with an attribute of type "Radio", name it "X", and add a value to it, name it "Y", with the "Free text" option selected. 2. From PoS, click the product, for the attribute "X", select the value "Y", and enter some text in the text input area "blabla". 3. Order the product. Observation: On the preparation display, only the attribute name and value are display, but not the entered text, i.e. "X: Y" instead of "X: Y: blabla". Fix: ---- We now show the custom value (free text) if any. This matches what's been shown on the receipt in PoS. opw-5111768
The ESG demo data was adjusted so it no longer depends on accounting records tied to a specific country setup. This prevents errors when loading demo data in fresh databases using India or other fiscal localizations, making setup more reliable.
Original PR description
**Note: issue not reproducible in runbot, but in fresh database** **Step to reproduce:** - in fresh database, install esg module - go to setting > invoicing > add india as Fiscal Localization -…
**Note: issue not reproducible in runbot, but in fresh database**
**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data
**Observation:**
- You will receive traceback
```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```
**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628
- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback
**Fix:**
- make demo data independent of any localization
opw-5048417A test related to SEPA credit transfers was corrected to follow the proper account number update process. This helps keep automated checks reliable and reduces the risk of issues when maintaining payment functionality.
Original PR description
Direct update sanitized_acc_number is not allowed. Forward-Port-Of: odoo/enterprise#95477 Forward-Port-Of: odoo/enterprise#72508
A Chilean electronic invoicing test now skips safely when optional demo data is not installed. This prevents false test failures in environments without demo data and helps keep validation runs consistent.
Original PR description
The test `test_demo_certificate_serial_number` failed when running without demo data, since the XMLID `l10n_cl_edi.l10n_cl_demo_certificate` is only present in demo mode. This commit updates the test to use `raise_if_not_found=False` and skip gracefully when the demo certificate is not available. The assertion now only runs if the certificate exists, ensuring the test passes consistently both with and without demo data. [RB-231573](https://runbot.odoo.com/odoo/error/231573)
Online rental product prices now use the website currency's configured decimal precision instead of always showing two decimals. This keeps public eCommerce prices consistent with business currency settings and avoids confusing price displays.
Original PR description
Versions -------- - 17.0 Steps ----- 1. Set currency precision to 0 decimals; 2. check prices in eCommerce as public user. Issue ----- Prices are displayed with 2 decimals Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. opw-4996878 Community PR: https://github.com/odoo/odoo/pull/224429 Forward-Port-Of: odoo/enterprise#95968 Forward-Port-Of: odoo/enterprise#95634
Website product prices now display using the correct currency precision, so currencies configured without decimals no longer show unnecessary cents. This keeps storefront pricing consistent for shoppers and website editors.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue…
Versions -------- - 17.0+ Steps ----- 1. Set currency rounding of EUR to 1.0; 2. use the currency on a website pricelist; 3. go to a product page in /shop; 4. open the url in a new session. Issue ----- From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals. Cause ----- The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element. Solution -------- Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`. For the product configurator, store the currency precision in the `.js_price_total` element's dataset. Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date. opw-4996878 Forward-Port-Of: odoo/odoo#229416 Forward-Port-Of: odoo/odoo#224429
This fixes an error that occurred when users switched Odoo to Italian while working with Italian tax returns. The Submit button is now identified in a language-independent way, preventing crashes for Italian-language users.
Original PR description
Steps: - Install 'l10n_it_xml_export' and switch to an Italian company - Install the Italian language - In Accouting Dashboard, configure the Tax Returns - Open the Tax Returns - Make sure you have a button 'Submit', review something if necessary - Switch the language to Italian - Traceback The xpath uses `text()` to select the element but the text in views is translated so the xpath does not work in all languages except English. We remove the check on text, `@name='action_submit'` should be enough. Ticket [link](https://www.odoo.com/odoo/project.task/5106966) opw-5106966
This fixes date-related inconsistencies in Mexican electronic invoicing sale tests by aligning expected payment policy behavior. It helps ensure automated checks remain reliable when timezone differences shift invoice dates around month-end.
Original PR description
### Steps to reproduce - In `l10n_mx_edi/tests/common.py`, change `cls.frozen_today` to any value between `2025-10-01 00:00:00` and `2025-10-01 05:59:59` - Run the `:TestCFDIInvoiceSale` tests - The…
### Steps to reproduce - In `l10n_mx_edi/tests/common.py`, change `cls.frozen_today` to any value between `2025-10-01 00:00:00` and `2025-10-01 05:59:59` - Run the `:TestCFDIInvoiceSale` tests - The tests fail because the payment policy is PPD whereas the expected XML has PUE ### Diagnosis The `sale.advance.payment.inv` wizard creates an invoice with `invoice_date_due = '2025-10-01'` but at post, we assign `invoice_date = '2025-09-30` due to this line: https://github.com/odoo/enterprise/blob/1f3c82635ee162987cf08490d447ad6d4121be4d/l10n_mx_edi/models/account_move.py#L838 As a result, the due date is in the month after the invoice date, so PPD is used as payment policy. ### Solution Force PPD by setting the due date to be 40 days after the invoice date, for consistency with the tests in `l10n_mx_edi`. #### Other solutions considered We could change the timezone in the context of the wizard, to make sure the due date is exactly the same as the invoice date, and keep PUE everywhere. runbot-233041
The messaging app no longer shows the translate option on messages that have no text, such as tracking updates or attachment-only messages. This avoids a confusing action that previously did nothing and keeps message options relevant to the content shown.
Original PR description
**Current behavior before PR:** The translate action was shown on all messages, including those with an empty body such as tracking updates or messages containing only attachments. Clicking the translate action on these messages had no effect. **Desired behavior after PR is merged:** The translate action is hidden for messages with an empty body. Only messages containing text display the translate option. **Task-5106303** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229595 Forward-Port-Of: odoo/odoo#228137
The sales planning test tour no longer depends on the current calendar date, which could fall on a non-working day and cause false failures. This makes automated checks more reliable without changing the business workflow for users.
Original PR description
Before this commit, the tour was failing on non-working days as the focused day was the current date. This commit removes the focus on the current date so that only working dates are selected. Additionally, this commit also fixes the formatting issues of the modified file. runbot error 226741
Messages that have already been received through another channel are now treated quietly when a later notification arrives. This prevents unnecessary chat windows from opening after the user has already seen the message in Discuss.
Original PR description
Before this commit, if a message was already received in the store by another medium than the bus, it was still handled not-silently when receiving the bus notification `discuss.channel/new_message`. This could lead to opening a chat window when a message was already seen by the user in the discuss app. This commit changes the handling of new messages in the frontend and overrides the silent flag when the record already exists. fixes-runbot-230700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Discount allocation settings now allow other income and other expense accounts to be selected. This prevents valid accounting accounts from being excluded, helping businesses configure discounts more accurately.
Original PR description
With this PR: - Updated the domain of discount allocation fields to include `income_other`/`expense_other` account types. Task-5121917 Forward-Port-Of: odoo/odoo#229026
The Danish Nemhandel journal dashboard now uses the shared fetching tool for retrieving statuses and bills. This keeps the user experience consistent and reduces module-specific handling for the same business action.
Original PR description
We can use the common tool to fetch status or bills for nemhandel --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal automated test so it only reacts to notifications from the database being tested. It helps keep Odoo's messaging infrastructure checks reliable without changing customer-facing behavior.
Original PR description
In [1], logs were added to the `test_postcommit` test in order to better understand why it sometimes fails. However, this commit changed the test behavior: we only care about notify coming from the DB executing the test, but the `channel` variable is filled regardless of the DB the notification comes from. [1]: https://github.com/odoo/odoo/pull/229106 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#229844
Mexican electronic invoices will no longer automatically replace a missing invoice date with the current date in the Mexico City timezone when posted. This avoids inconsistent invoice and due dates and makes invoice behavior more predictable.
Original PR description
At the moment, when an invoice that uses a CFDI is posted, the invoice date (if not already existing) is set to the current date in the Mexico City timezone. This default behaviour is just weird, and even if there might have been technical reasons for it in the past, these are no longer valid. This can also cause the default invoice date to be different from the default due date, which causes unexpected behaviour in tests. We therefore remove this override. runbot-233041
Point of Sale session names now remain sequential when cash posting fails. This avoids skipped session numbers, making records easier to follow and reconcile for store operations.
Original PR description
Before this commit, if an issue occurred while posting the cash details, the session sequence would still increment even though the operation failed, leading to gaps in session names. With this commit, the sequence only increments when the operation succeeds, ensuring continuous session naming without gaps. opw-5100163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229719 Forward-Port-Of: odoo/odoo#229532