Monday, June 2, 2025
61 changes
12 changes
Resolved issues and error corrections
This update makes an automated accounting test more stable by avoiding a changing field identifier and waiting for the amount field to be ready. It helps reduce false build failures, improving confidence in release validation without changing user-facing behavior.
Original PR description
The `account_accountant_tour` test was failing at the step that attempts to set an amount, due to the selector `input[id=amount_0]` not being found within the timeout. The root cause was that the selector used an ID (`amount_0`) which is dynamically generated and can change across test runs . To resolve this, the selector was replaced with a more stable one: `div[name=amount] input`, which targets the same field but does not rely on dynamic IDs. Additionally, a no-op wait step was introduced immediately before this interaction to ensure the DOM has fully rendered the input element before the test proceeds. build_error-220890
This fixes an error that could occur when searching or grouping documents by last access date with empty values. The change helps prevent unexpected failures in the Documents app and keeps document filtering more reliable.
Original PR description
…n values. A small error was been made in https://github.com/odoo/enterprise/pull/76079 (`_search_last_access_date_group`): the SQL string contains a %s without an argument, resulting in a "TypeError: not enough arguments for format string." Fix it. A test will be added later to the master branch in a later PR that found the issue https://github.com/odoo/odoo/pull/133224. https://github.com/odoo/odoo/pull/212115
Closing an AI agent chat box no longer causes an error when the chat has not been linked to a conversation. This prevents an unexpected crash and gives users a smoother experience in the AI module.
Original PR description
The system will crash because `AIAgent.close_chat()` requires a `channel_id`, and if `component.thread?.id` is undefined, it results in a missing argument error.
**Steps to Produce:-**
1. Install the `AI` module.
2. Navigate to the AI module. If an agent is already present, click on it. Otherwise, create a new agent.
3. Click on the agent to open the chat box.
4. Close the chat.
**Error:-**
`TypeError: AIAgent.close_chat() missing 1 required positional argument: 'channel_id'`
**Solution:-**
- Check that `component.thread.id` is present before calling
`AIAgent.close_chat`.
**Sentry : 6388425767**Miscellaneous changes
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data
Original PR description
## opw-4812933 feedback > When attachments were exported from Studio Export, they got exported in descending order by id (from highest id to lowest id). This caused a problem during import: if an attachment referred to an earlier one using a "Resource ID" (meaning it depended on a previously created attachment), the dependent attachment would try to import before the one it needed. This led to an error because the referenced attachment didn't exist yet. ## found issue The exported data is sorted to ensure import order is correct, but for inter-record dependencies on a same model many2one_reference fields are not taken into account. This PR fixes that. Also while analyzing this issue another small issue was spotted regarding base.automation.url field. See commits. Forward-Port-Of: odoo/enterprise#86407 Forward-Port-Of: odoo/enterprise#86204
13 changes
Resolved issues and error corrections
This fixes a mail-sending issue where Odoo could raise an error if the SMTP connection had already been closed. The change helps email processing finish more reliably and reduces avoidable failures during outgoing mail handling.
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
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. A first attempt was made to blacklist the module in the test itself. This attemps failed as the module is auto_install on `hr_payroll` and most of `l10n_hr*` modules depend on `hr_payroll`. Forward-Port-Of: odoo/enterprise#86758
Original PR description
The `all_l10n` standalone test started to fail on 2025-06-01 when installing `l10n_in_hr_payroll`. A first attempt was made to blacklist the module in the test itself. This attemps failed as the module is auto_install on `hr_payroll` and most of `l10n_hr*` modules depend on `hr_payroll`. Forward-Port-Of: odoo/enterprise#86758
The "Fetch from CodaBox" link displayed on the accounting dashboard had no gap between it and the button at the left of it, and wasn't aligned horizontaly with the other buttons next to it making it look out of place. It is now displayed as a link button, which solve both problems. task-4671468 Purpose The fetch from CodaBox is too sticky to the upload button  After this commit :  After this commit :  Forward-Port-Of: odoo/enterprise#84858
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity
Original PR description
Fix qty_delivered when a rental order is processed through the PoS. This commit ensure that the PoS qty_delivered computation is done after the other calculation Steps to reproduce: ------------------- * Make a rental for 1 product * Open the sale order in PoS * Pay for the rental > Observation: The qty_delivered is set to 2 instead of 1 on the rental Why the fix: ------------ When the order is a rental processed through the PoS, we recompute the rental qty and add the PoS quantity to make sure that the value is correct. The computation is actually just the fusion of the PoS and rental _compute_qty_delivered methods. opw-4582505 Forward-Port-Of: odoo/enterprise#86266 Forward-Port-Of: odoo/enterprise#84768
Needed internally where the cart is not always in the company of the website. Forward-Port-Of: odoo/enterprise#86236
Original PR description
Needed internally where the cart is not always in the company of the website. Forward-Port-Of: odoo/enterprise#86236
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4 - Open Document and go to marketing folder There is no thumbnail for the uploaded image. In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is inco
Original PR description
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4…
How to reproduce: - Install document in v17.0 with demo data - In the kanban view, upload an image in Marketing folder - The image is displayed as thumbnail in the kanban card - Upgrade to saas-17.4 - Open Document and go to marketing folder There is no thumbnail for the uploaded image. In v17, _compute_thumbnail_status write a False status when the thumbnail is updated because when it is trigerred the attachment is not yet created. So the thumbnail is present but its status is incorrect. It works in v17 because the status is ignored by the view for images but in v17.4, the status is not ignored and the thumbnail is then not displayed. This temporary fix allows already migrated user to see thumbnail (as the view could not be modified in stable without an upgrade). We force the status of the thumbnail to "present" when there is no status for a thumbnail of an image which should cover the case where the status was not updated after the thumbnail creation. We have chosen this solution as the thumbnail will be updated in the upgrade and the URL returns anyway a placeholder image if the image is not present. We modify some tests to check that the patch is applied. As the kanban test data includes an image with a False status, the patch turns automatically the status to "present". So instead of having the generic mime type thumbnail, we get the actual thumbnail of the image. We change the assertions accordingly to test the new behavior and test the generic mime type thumbnail in the pdf case of the test "document inspector: document preview". Task-4642866 Forward-Port-Of: odoo/enterprise#85751 Forward-Port-Of: odoo/enterprise#81558
Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246 Forward-Port-Of: odoo/enterprise#85857
Original PR description
Update on the filterExchangeRate function. The text input allowed users to enter non-numeric characters, which led to float conversion errors during processing. Now we parse the string into a float, catch errors and notify the user that the number was not valid. It also enables the user to use the thousands and decimal separators based on the language of the user. opw-4788246 Forward-Port-Of: odoo/enterprise#85857
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a different value. 4) Post the journal 5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" <b>Issue:</b> The line for the created journal entry has a price_total of the previous balance even after updating the
Original PR description
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a…
<b>Steps to produce :</b> 1) Install 10n_de_reports and switch to the German company 2) Create a journal entry from accounting with a credit and debit 3) Now update the credit and debit to a different value. 4) Post the journal 5) Go to "Accounting / Reporting / Audit Reports / General Ledger" 6) Download "DATEV DATA (ZIP)" and check "EXTF_accounting_entries.csv" <b>Issue:</b> The line for the created journal entry has a price_total of the previous balance even after updating the credit and debit values. <b>Cause:</b> When the user updates the 'debit' and 'credit' values for an `aml`, The `price_totals` value remains unchanged as it is not dependent on `balance`. So, it will show the previous value in the report line because we are taking the abs(aml.price_total) from the report data. <b>Solution:</b> We can add an extra check of the move type so that it will fall back to the else block, where the line_amount will take a value by calculating taxes from `aml.tax_ids.compute_all`. opw-4707567 Forward-Port-Of: odoo/enterprise#83777
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#86240 Forward-Port-Of: odoo/enterprise#43574
Invoice PDFs now handle very long tax group names without pushing total amounts off the page. This keeps invoice totals visible and readable for customers and accounting teams.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A small configuration error in the self-order testing setup was corrected. This helps keep automated checks reliable so issues in the customer self-order flow can be caught before release.
Original PR description
The test for the self-order feature was failing due to a validation error in the web_tour registry. The issue comes from the use of an unrecognized key 'test' in the tour configuration of 'self_order_pricelist'. This change removes the invalid 'test' key from the tour definition.
The website shop payment form now consistently receives the related sales order information. This helps customizations and extensions work reliably when they depend on order details during checkout.
Original PR description
Before this commit, sale_order information were used in some payment form but only website_sale_order was available. This would cause issue in overrides. task 4808806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds test coverage for an issue where copying an invoice could unintentionally change the original invoice. This helps ensure future fixes protect existing accounting records from unwanted changes during duplication.
Original PR description
When duplicating an account move, the origin move shouldn't be modified. The reason for that is when `create` is called, operations are done on self, like check and sync balance, which is wrong. create is an `api.model` method and shouldn't alter the record if set. This PR doesn't include a fix, just tests that reproduces issue explained on ticket `#4823689` ping @william-andre --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The self-ordering carousel test now uses the point-of-sale session's test mode instead of waiting for a timeout. This makes automated checks more stable and helps prevent false failures without changing the customer-facing experience.
Original PR description
In this commit: =============== - We use session.test_mode instead of relying on a timeout while testing the carousel in all self-ordering modes in test_self_order_pos_landing_page_carousel Runbot error: 226322
This fix makes an automated live chat check wait until the web client is fully ready before continuing. It reduces false failures in quality checks, helping keep live chat behavior stable without changing the user-facing experience.
Original PR description
runbot-error-108129 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
This fixes an issue where certain online sales configuration options could be hidden when the system could not determine whether the related view was enabled. The intended behavior is restored so the option remains visible by default, helping avoid missing choices during website purchase configuration.
Original PR description
commit 163b337fce6d3d67412f0e34e8120fbd5d02f463 didn't take into consideration that is_view_enabled can return None and the intended default behavior should be to show it by default --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update gives an internal messaging test more time to confirm websocket subscriptions, reducing occasional false failures when systems are under heavy load. It helps keep automated quality checks stable without changing customer-facing behavior.
Original PR description
The test "Message shows up even if channel data is incomplete" can occasionally fail, most likely due to high CPU usage. The websocket subscription check is timing out too early. Increase the timeout, as done in 18.1, to reduce the likelihood of such failures. runbot-224044
Miscellaneous changes
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
Original PR description
Added FI and LT, and updated extra terms for others. Related to https://github.com/odoo/enterprise/pull/86440 Forward-Port-Of: odoo/odoo#211753 Forward-Port-Of: odoo/odoo#211714
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
When computing the payment state fetching the payment data from the database is only necessary for posted invoices. Previously it was fetched all the time which causes unnecessary requests to the database and can cause performance issues when a lot of non invoice entries are being processed concurrently. With inventory valuation for instance. opw-4724142 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#209471 Forward-Port-Of: odoo/odoo#208850
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Original PR description
**Issue:** when you change an odoo event organizer the original gets archived and a new one is created this behavior should only be happening with microsoft synced events **Steps to reproduce:** - install microsoft_calendar - create new event - change organizer and save the event is archived opw-4765254 Forward-Port-Of: odoo/odoo#210100
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice t
Original PR description
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's…
Description of the issue/feature this PR addresses: - This PR changes the TD05 to be considered a Vendor Bill instead of a Vendor Credit Note, when uploading document in Purchase journal in Italy's localization. - This PR adds a new bridge module such that if database has `l10n_it_edi_ndd` module then it automatically installs `account_debit_note`. This ensures the `account.move` model contains the fields required. The new module contains logic to change the debit note of a customer invoice to be considered a TD05 instead of a TD01. The debit note used to take the document id of the original customer invoice, which is TD01. So `l10n_it_document_type` field is set as non-copy. A `debit_note` key is added in the mapping of invoice features to document features if the invoice is a debit note. - The tag in the XML template with the invoice linked to the debit note was changed based on requirements. Also, reference invoice name and date were added in XML if invoice is debit note. tasks-4744444 Current behavior before PR: - When uploading TD05 in the Purchase journal, it's considered a Vendor Credit Note. - When creating a debit note from a customer invoice, the new invoice has TD01 document type Desired behavior after PR is merged: - When uploading TD05 in the Purchase journal, it's considered a Vendor Bill. - When creating a debit note from a customer invoice, the new invoice has TD05 document type --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209072