Wednesday, April 9, 2025
51 changes · saas-18.2
Resolved issues and error corrections
This fixes an issue where PDF signature checks could fail because the signing time was generated at slightly different moments. By using the same signing time for the expected and actual signature, tests and signature generation become more reliable without changing user-facing behavior.
Original PR description
so that the expected and actual signature match the signing time needs to match too , any slight delay between the date generation would fail the test build_error-134224
This fixes a shop page error that could occur when someone manually changed a product URL to use a category that does not exist. Visitors will no longer hit a server error in this edge case, improving storefront reliability.
Original PR description
Currently, an error occurs when the category ID is manually changed in the website URL. Steps to Reproduce: --- - Install the `website_sale` application - Website > Shop > Select any category > Open any product - Change category ID in URL(eg: category=91) Traceback: --- ValueError: Cannot slug non-existent record product.public.category() At [1], an error occurs when adding a manual category ID because it does not exist in the `product.public.category` model, resulting in an empty return when browsing it. [1]- https://github.com/odoo/odoo/blob/74aa68d159b0708b09495956d23d51e3acef9bb5/addons/website_sale/controllers/main.py#L669 sentry-6407561181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue in Mail Groups where clicking "read more" could leave some quoted sections hidden or trigger an error. Users should now see the full quoted content reliably when expanding messages.
Original PR description
Problem 1: The js selects only the first element with the html data-o-mail-quote attribute but there may be more than one. Thus, some elements were not displayed when user clicked on the "read more" button. Now, they are all displayed when the user clicks on this one. Problem 2: The js selects an element with the html data-o-mail-quote attribute and try to use js attributes of the returned object but this one can be null. Then the error occurs. From now, we use its attributes if its is not null. Problem 3: The add method of classList contains spaces. Now, the list of classes is split by commas. Part-of: odoo/odoo#190032 Backport of: https://github.com/odoo/odoo/commit/37303f505c4486766822f9012b257b24ff19543a
PDF signing requests now open more cleanly on mobile by keeping the sidebar closed by default. This makes documents easier to view and control on smaller screens, while desktop users continue to see the thumbnail sidebar by default.
Original PR description
### Before this commit: If a pdf file is open on mobile, the sidebar is open and it is hard to control. ### After this commit: If the app is open on mobile, the sidebar is not open. Otherwise, it is open and the page modes is thumbs by default. task-4626059
Appointment booking links now use hyphens instead of underscores and avoid duplicate link conflicts. This makes shared booking URLs easier to read and helps ensure each appointment configuration gets a working, unique link.
Original PR description
1. Replace "_" with "-" for name generation. eg. "appointment_with me" to "appointment-with-me"
2. Generate a unique link.
Case 1: generate "-" based link when no link exists for the appointment eg. "/schedule-a-demo".
Case 2: if a link exists for the appointment -> generate random code if appointment name based short code is
already used in another configuration.
Task-4610207Miscellaneous changes
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In t
Original PR description
Steps to reproduce ================== - In 18, go to a view with an always invisible many2one field - Enable debug mode - In the debug menu, click on "Set defaults" => Cannot read properties of undefined (reading 'length') Cause of the issue ================== We only fetch the display name for many2one that are not always invisible https://github.com/odoo/odoo/blob/6a1c38a83a1a9108ae4cbfe36bf787bef02de063/addons/web/static/src/model/relational_model/utils.js#L383-L384 In that case, `displayed` will be undefined. a0732ec87edbb7fee6ebc76ea093bc8a52fd3fad didn't check if displayed was defined. It also checked the length of non-string values. While it doesn't cause an error, it doesn't make sense. A comparison of `typeof displayed === "string"` is not enough, because we also need to handle Markup elements. opw-4572496 Forward-Port-Of: odoo/odoo#205368 Forward-Port-Of: odoo/odoo#204816
Before this commit, when automatic receipt printing was enabled, a POS printer was configured, and the "Skip Preview" option was not enabled, the POS remained on the Payment screen after order validation instead of switching to the Receipt screen. opw-4656023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205037
Original PR description
Before this commit, when automatic receipt printing was enabled, a POS printer was configured, and the "Skip Preview" option was not enabled, the POS remained on the Payment screen after order validation instead of switching to the Receipt screen. opw-4656023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205037
Change used category in test from `Chairs` which is demo data to `Chair Test` runbot error: 162925, 162923 Forward-Port-Of: odoo/odoo#205189
Original PR description
Change used category in test from `Chairs` which is demo data to `Chair Test` runbot error: 162925, 162923 Forward-Port-Of: odoo/odoo#205189
When the order is sent to the preparation tools, synchronization is performed twice. This is because synchronization is done in the preparation tool method and in the unsetTable method. Add last synchronization date to order states. If it has been synchronized within 2 seconds, the second call is not made. taskId: 4664549 Forward-Port-Of: odoo/odoo#203419
Original PR description
When the order is sent to the preparation tools, synchronization is performed twice. This is because synchronization is done in the preparation tool method and in the unsetTable method. Add last synchronization date to order states. If it has been synchronized within 2 seconds, the second call is not made. taskId: 4664549 Forward-Port-Of: odoo/odoo#203419
The upload file action is available in the comment composer, but it's not relevant to what this composer is expected to do, and it doesn't work there. This PR removes that action from the comment composer. part of task-4712487 Forward-Port-Of: odoo/odoo#205202
Original PR description
The upload file action is available in the comment composer, but it's not relevant to what this composer is expected to do, and it doesn't work there. This PR removes that action from the comment composer. part of task-4712487 Forward-Port-Of: odoo/odoo#205202
**Steps to reproduce the bug:** - Create a storable product - Archive it - Refresh the page **Problem:** A traceback is triggered: `TypeError: Cannot read properties of undefined (reading 'uom_id')` This happens because, during setup, the updateReferenceUnit function is called: https://github.com/odoo/odoo/blob/9fb46cdbc553e7ac91aeccf9779af37c018a7327/addons/uom/static/src/components/many2x_uom_tags/many2x_uom_tags.js#L38 In this function, a "search_read" is performed to fetch th
Original PR description
**Steps to reproduce the bug:** - Create a storable product - Archive it - Refresh the page **Problem:** A traceback is triggered: `TypeError: Cannot read properties of undefined (reading 'uom_id')`…
**Steps to reproduce the bug:** - Create a storable product - Archive it - Refresh the page **Problem:** A traceback is triggered: `TypeError: Cannot read properties of undefined (reading 'uom_id')` This happens because, during setup, the updateReferenceUnit function is called: https://github.com/odoo/odoo/blob/9fb46cdbc553e7ac91aeccf9779af37c018a7327/addons/uom/static/src/components/many2x_uom_tags/many2x_uom_tags.js#L38 In this function, a "search_read" is performed to fetch the product: https://github.com/odoo/odoo/blob/9fb46cdbc553e7ac91aeccf9779af37c018a7327/addons/uom/static/src/components/many2x_uom_tags/many2x_uom_tags.js#L43 However, by default, the search only looks for non-archived products. As a result, the archived product isn't found, and the code still tries to access its uom, which leads to an error: https://github.com/odoo/odoo/blob/9fb46cdbc553e7ac91aeccf9779af37c018a7327/addons/uom/static/src/components/many2x_uom_tags/many2x_uom_tags.js#L44 opw-4701779 Forward-Port-Of: odoo/odoo#205041
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the app
Original PR description
Added condition on check that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. opw-3841495 Forward-Port-Of: odoo/odoo#204747 Forward-Port-Of: odoo/odoo#178142
Steps: - In the restaurant, navigate to the ticket screen from the floor screen. - Select any paid order. - The Refund button should be visible below the numpad but isn't. Issue: - The `ActionpadWidget` is only displayed if a current order is set. However, on the floor screen, no current order exists. Fix: - Removed the dependency of `ActionpadWidget` on the current order. Task: 4658232 Back-Port-Of: odoo/odoo#202492 Forward-Port-Of: odoo/odoo#204563
Original PR description
Steps: - In the restaurant, navigate to the ticket screen from the floor screen. - Select any paid order. - The Refund button should be visible below the numpad but isn't. Issue: - The `ActionpadWidget` is only displayed if a current order is set. However, on the floor screen, no current order exists. Fix: - Removed the dependency of `ActionpadWidget` on the current order. Task: 4658232 Back-Port-Of: odoo/odoo#202492 Forward-Port-Of: odoo/odoo#204563
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Enterprise PR: https://github.com/odoo/enterprise/pull/81644 task-4587067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-P
Original PR description
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Enterprise PR: https://github.com/odoo/enterprise/pull/81644 task-4587067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204858 Forward-Port-Of: odoo/odoo#202228
Before this commit: === - Orders with a preset time in the future (not for today) were automatically canceled in the preparation display when the session was closed. After this commit: === - Future-dated orders are no longer canceled in the preparation display when closing the session. related-https://github.com/odoo/enterprise/pull/78345 task-4523422 Forward-Port-Of: odoo/odoo#196122
Original PR description
Before this commit: === - Orders with a preset time in the future (not for today) were automatically canceled in the preparation display when the session was closed. After this commit: === - Future-dated orders are no longer canceled in the preparation display when closing the session. related-https://github.com/odoo/enterprise/pull/78345 task-4523422 Forward-Port-Of: odoo/odoo#196122
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of
Original PR description
Because #203874 needed to manipulate Odoo imports, it had to be able to import Odoo. Turns out there are setups where the root of the community repository is on `sys.path` but not in `PYTHONPATH` which can lead the pylint invocation to be confused and not have `odoo` be reachable from the `PYTHONPATH`, thus crashing the plugins' loading. Thus to run pylint we need not the `PYTHONPATH` but the `sys.path`. Which is not ideal because that'll contain the paths to the site and standard library of the python running the test, which might be different than the python running pylint. To limit the risks of contamination, strip out any path starting with one of the `sys.$CATEGORY_prefix` entries. Forward-Port-Of: odoo/odoo#205194
### Steps to reproduce: - Go to settings, set the overtime of an attendance to be validated by a manager - Go to attendance, create an attendance with an overtime - Worked Extra Hours and Extra Hours are the same - Refuse the overtime - Extra Hours is not 0 ### Cause: This is happening because when computing the overtime validated hours we are just setting it equals to the worked extra hours value when the status of the attendance is to_approve but when it got refused we don't re-com
Original PR description
### Steps to reproduce: - Go to settings, set the overtime of an attendance to be validated by a manager - Go to attendance, create an attendance with an overtime - Worked Extra Hours and Extra Hours are the same - Refuse the overtime - Extra Hours is not 0 ### Cause: This is happening because when computing the overtime validated hours we are just setting it equals to the worked extra hours value when the status of the attendance is to_approve but when it got refused we don't re-compute the value. https://github.com/odoo/odoo/blob/0d0c1bc7c075f49a461c66a433e20b431276ff12/addons/hr_attendance/models/hr_attendance.py#L164-L166 ### Fix: We are overriding the value for the validated overtime hours now when it got refused and set it equals to 0 opw-4675268 Forward-Port-Of: odoo/odoo#204792
I spotted three mistakes in the naming of the lines in the Modelo 303 and 390 reports. This PR fixes them and updates the .po, .pot files accordingly. Forward-Port-Of: odoo/odoo#201810 Forward-Port-Of: odoo/odoo#200201
Original PR description
I spotted three mistakes in the naming of the lines in the Modelo 303 and 390 reports. This PR fixes them and updates the .po, .pot files accordingly. Forward-Port-Of: odoo/odoo#201810 Forward-Port-Of: odoo/odoo#200201
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: |
Original PR description
### Description: When confirming a sale order with products on MTO, it can trigger the method _run_manufacture to generate the manufacturing order linked to it. However, this part can take a long time to be processed because of the multiple compute stored triggered on the way (mostly from the field `move_finished_ids`). ### Fix: To speed this up, we can extract the deletion of the previous finished moves so the ORM can batch delete in `_compute_move_finished_ids`. ### Benchmark: | # of lines with MTO | Before | After | |---------------------|---------|--------| | 20 | 3:48 | 2:48 | | 10 | 1:45 | 1:18 | ### Reference: opw-4629884 Forward-Port-Of: odoo/odoo#204808
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/82351 --- I confirm I have s
Original PR description
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/82351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205087 Forward-Port-Of: odoo/odoo#203713
When refreshing during tours, we need to ensure that all indexedDB transaction are done, otherwise we can have some issues. Runbot errors: 161900, 161901 X-original-commit: https://github.com/odoo/odoo/commit/5c775bdb04e03a24b2706676d4665fa4b21eed21
Original PR description
When refreshing during tours, we need to ensure that all indexedDB transaction are done, otherwise we can have some issues. Runbot errors: 161900, 161901 X-original-commit: https://github.com/odoo/odoo/commit/5c775bdb04e03a24b2706676d4665fa4b21eed21
See https://github.com/odoo/enterprise/pull/82873 for the updated test. In commit 9e84f87, some refactoring was made to tax calculation in order to make it easier to override. However, a bug was introduced in the `prepareProductBaseLineForTaxesComputationExtraValues` of the product template model, where the default `false` value would be incorrectly used, leading to a price of 0. Steps to reproduce: - Configure a scale in the POS - Add a weighed product, e.g. the demo 'Flour' product -
Original PR description
See https://github.com/odoo/enterprise/pull/82873 for the updated test. In commit 9e84f87, some refactoring was made to tax calculation in order to make it easier to override. However, a bug was introduced in the `prepareProductBaseLineForTaxesComputationExtraValues` of the product template model, where the default `false` value would be incorrectly used, leading to a price of 0. Steps to reproduce: - Configure a scale in the POS - Add a weighed product, e.g. the demo 'Flour' product - In the scale popup, observe that the price per unit (and therefore total price) is 0.00 task-4702650 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204757
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
Original PR description
The UNECE code mapping for Nilvera was done in l10n_tr_nilvera_einvoice. here at #193030 However later that was needed in l10n_tr_nilvera_edespatch and that too in stock_move. This PR moves the mapping from l10n_tr_nilvera_einvoice to l10n_tr_nilvera so that it can be used by both einvoice and edespatch. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204457
### Steps to reproduce: - Install "l10n_it_edi" and switch to Italian company - Accounting > Customers > Invoices - Create a new invoice - Add a partner and go to this partner form - Change the field "Codice Fiscale" with a lowercase value, like "Mrtmtt91d08f205j" - Confirm the invoice and send it to the Tax Agency - The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to
Original PR description
### Steps to reproduce: - Install "l10n_it_edi" and switch to Italian company - Accounting > Customers > Invoices - Create a new invoice - Add a partner and go to this partner form - Change the field "Codice Fiscale" with a lowercase value, like "Mrtmtt91d08f205j" - Confirm the invoice and send it to the Tax Agency - The `CodiceFiscale` field in the XML contains lowercase letters, which is not accepted by the government ### Solution: Change `_l10n_it_edi_normalized_codice_fiscale` to return the uppercase value. (Already the case for "Destination Code (SDI)") To increase the user experience, also add `text-uppercase` on the input in `l10n_it_edi_website_sale` so the text entered there is always capital. Same for "Destination Code (SDI)". opw-4655364 Forward-Port-Of: odoo/odoo#205052 Forward-Port-Of: odoo/odoo#203217
Previously, when installment_state was None, the template raised an error because None in ('next', 'overdue') is not a valid operation. This change ensures safe access to installment_state using .get(), preventing potential errors when the key is missing or its value is None. **Description of the issue/feature this PR addresses:** The invoice template was raising an error when installment_state was None, as the condition None in ('next', 'overdue') is invalid. **Current behavior before
Original PR description
Previously, when installment_state was None,
the template raised an error because None in ('next', 'overdue') is not a valid operation.
This change ensures safe access to installment_state using .get(), preventing potential errors when
the key is missing or its value is None.
**Description of the issue/feature this PR addresses:**
The invoice template was raising an error when installment_state was None, as the condition None in ('next', 'overdue') is invalid.
**Current behavior before PR:**
If installment_state is None, the template crashes due to an invalid comparison.
**Desired behavior after PR is merged:**
The template now safely retrieves installment_state using .get(), preventing errors when the key is missing or its value is None.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#202689### Steps to reproduce: - Create a contact with a very very long name - Change the layout of documents to "Bubble" - Create an invoice with the new contact - Confirm and Print - The invoice title is unaligned or cropped ### Cause: The layout is using a flexbox to display the contact and the title on the same level. But flex boxes are not supported by whtmltopdf so the result is random. ### Solution: Use a `table` mimicking the flex display. Before: ![image](https://github.com/us
Original PR description
### Steps to reproduce: - Create a contact with a very very long name - Change the layout of documents to "Bubble" - Create an invoice with the new contact - Confirm and Print - The invoice title is unaligned or cropped ### Cause: The layout is using a flexbox to display the contact and the title on the same level. But flex boxes are not supported by whtmltopdf so the result is random. ### Solution: Use a `table` mimicking the flex display. Before:  After:  opw-4653504 Forward-Port-Of: odoo/odoo#203244
Before this commit: When a user opened a form view and clicked browser's Back button, then immediately clicked on the breadcrumb, a traceback occurred. After this commit: Navigation works smoothly without crashes. Task-4667911 Forward-Port-Of: odoo/odoo#204492
Original PR description
Before this commit: When a user opened a form view and clicked browser's Back button, then immediately clicked on the breadcrumb, a traceback occurred. After this commit: Navigation works smoothly without crashes. Task-4667911 Forward-Port-Of: odoo/odoo#204492
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human readable format, the XML invoice itself will still be added as an attachment as specified in ISO 19005-3 titled "Document management - Electronic document file format for long -term preservation - Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", and contain the compliant
Original PR description
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human…
Description of the issue/feature this PR addresses: As per ZATCA, `For electronic invoices generated in PDF/A-3 format: while the PDF content will be the representation of the XML invoice in a human readable format, the XML invoice itself will still be added as an attachment as specified in ISO 19005-3 titled "Document management - Electronic document file format for long -term preservation - Part 3: Use of ISO 32000-1 with support for embedded files (PDF/A-3)", and contain the compliant XML invoice as an embedded object.` Current behavior before PR: - Generated Saudi Localization PDF Invoice had not embedded attached EDI XML documents - Generated Saudi Localization PDF Invoice was not PDF-A Compliant - Generated Saudi Localization PDF Invoice file name did not adhere to ZATCA business rules of the following: `Seller Vat Number (BT-31), Date (BT-2), Time (KSA-25), Invoice Number (BT-1)` Desired behavior after PR is merged: - Generated Saudi Localization PDF Invoice has the XML EDI documents embedded as an attachment - Generated Saudi Localization PDF Invoice is PDF-A Compliant - Generated Saudi Localization PDF Invoice is named as per the ZATCA business rules --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr opw-4528551 Forward-Port-Of: odoo/odoo#204852 Forward-Port-Of: odoo/odoo#198158
Recently, we've face an issue when multiple orders were opened. When one of them was paid, loyalty points were applied for all other opened orders. A fix has been applied to correct the situation: https://github.com/odoo/odoo/commit/2dcad5f32693471588bbe605601d3346b14196be Afterward it appears that the fix does not get rid of the problem 100% of the time. When there are more than 1 order on the payment screen with payment lines covering the total amount, and when one of them is finalized,
Original PR description
Recently, we've face an issue when multiple orders were opened. When one of them was paid, loyalty points were applied for all other opened orders. A fix has been applied to correct the situation:…
Recently, we've face an issue when multiple orders were opened. When one of them was paid, loyalty points were applied for all other opened orders. A fix has been applied to correct the situation: https://github.com/odoo/odoo/commit/2dcad5f32693471588bbe605601d3346b14196be Afterward it appears that the fix does not get rid of the problem 100% of the time. When there are more than 1 order on the payment screen with payment lines covering the total amount, and when one of them is finalized, the other orders are also getting points applied. Why the fix: ------------ The fix mentionned above uses `is_paid()` as a filter to select which orders should get points applied. It seems like `is_paid` is intended to be used to know if the payment lines cover the order amount before the order is truly finalized. https://github.com/odoo/odoo/blob/8be96595ce5795df25b9b7dbea14a0f8c75a804c/addons/point_of_sale/static/src/app/models/pos_order.js#L905-L911 We change the condition to be based on the state of the order instead. opw-4677541 Forward-Port-Of: odoo/odoo#205088 Forward-Port-Of: odoo/odoo#204942
Issue Before This Commit: ============================ When attempting to add a new valuation for a lot/serial-tracked product using the 'Add Manual Valuation' button while the 'Group By Lot' filter is applied, a 'ZeroDivisionError: float division by zero' traceback occurs. Steps to Reproduce: ============================ - Install the stock_account module. - Create a product, enable Lot/Serial tracking, and assign it to the Furniture category. - Update the quantity and assign a lot
Original PR description
Issue Before This Commit: ============================ When attempting to add a new valuation for a lot/serial-tracked product using the 'Add Manual Valuation' button while the 'Group By Lot' filter…
Issue Before This Commit: ============================ When attempting to add a new valuation for a lot/serial-tracked product using the 'Add Manual Valuation' button while the 'Group By Lot' filter is applied, a 'ZeroDivisionError: float division by zero' traceback occurs. Steps to Reproduce: ============================ - Install the stock_account module. - Create a product, enable Lot/Serial tracking, and assign it to the Furniture category. - Update the quantity and assign a lot/serial number, which creates a valuation layer for this lot-tracked product. - Disable Valuation by Lot/Serial Number for the product. - Go to Valuation, apply the Group By Lot filter, and try to create a new valuation by clicking Add Manual Valuation. - Click on the Revalue button it will give an Error. With This Commit: ============================ The issue occurs because when revaluing layers using the 'Add Manual Valuation' button, all layers have 0 remaining quantity. This happens if 'Valuation by Lot/Serial Number' was initially enabled, creating valuation layers for lot/serial-tracked products, and later disabled. As a result, all valuation layers associated with lot/serial numbers have zero remaining quantity. When attempting to revalue these layers while using the 'Group By Lot' filter, the error occurs. This commit ensures that if all layers have 0 remaining quantity, a validation error is raised to prevent the issue. task - [4668497](https://www.odoo.com/odoo/my-tasks/4668497) Forward-Port-Of: odoo/odoo#203097
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing. To reproduce this issue: 1) Install `mass_mail` 2) Create new mailings with `contact_list_ids` and make sure to give the value for `preview` in the settings page. 3) Don't select any `Mail Body` templates. 4) Schedule the record with the `previous day`. 5) An Error was encountered in the terminal. Error:- ``` TypeError: expected string or bytes-like object ``` A corn job runs w
Original PR description
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing. To reproduce this issue: 1) Install `mass_mail` 2) Create new mailings with `contact_list_ids` and make…
This traceback occurs when the user schedules a mail without a `Mail Body` in email marketing.
To reproduce this issue:
1) Install `mass_mail`
2) Create new mailings with `contact_list_ids` and make sure to give
the value for `preview` in the settings page.
3) Don't select any `Mail Body` templates.
4) Schedule the record with the `previous day`.
5) An Error was encountered in the terminal.
Error:-
```
TypeError: expected string or bytes-like object
```
A corn job runs when the user `schedules` a mail, in which `action_send_mail` triggers.
In that method while composing values, `body` is used to get values from `mail.body_html`.
https://github.com/odoo/odoo/blob/e37c393d415d686584487f9ad92f062279504cf8/addons/mass_mailing/models/mailing.py#L1043-L1046
Because when the user doesn't select the body template its value will be `false` which leads to the above traceback,
as the `re.search` method is used between preview and body.
https://github.com/odoo/odoo/blob/e37c393d415d686584487f9ad92f062279504cf8/odoo/tools/mail.py#L500
This commit will resolve the issue by giving a fallback value of empty string when the user doesn't select the body template.
sentry-5983589884
Forward-Port-Of: odoo/odoo#204167
Forward-Port-Of: odoo/odoo#166962## Version: 18.0+ ## Issue: PDF invoices in boxed document layout always display a black font for total amount value only for Chile. This black font is not easily readable for most background colors (incl. standard background). ## Steps to reproduce: - Navigate to the Settings app: - Under the `Companies` section, configure the document layout: - Ensure the `Boxed` layout is selected; - Navigate to the Invoicing app: - Open any invoice record from `Customers / Invoices`;
Original PR description
## Version:
18.0+
## Issue:
PDF invoices in boxed document layout always display a black font for total amount value only for Chile. This black font is not easily readable for most background colors (incl. standard background).
## Steps to reproduce:
- Navigate to the Settings app:
- Under the `Companies` section, configure the document layout: - Ensure the `Boxed` layout is selected;
- Navigate to the Invoicing app:
- Open any invoice record from `Customers / Invoices`;
- Via the `Actions` gear button, print the `PDF without Payment`.
## Cause:
Template inconsistency compared to standard report template: https://github.com/odoo/odoo/blob/3ebd200a76d490ed97bc164e80ed2837fb2f650f/addons/account/views/report_invoice.xml#L443-L450.
opw-4698105
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#204592Description of the issue/feature this PR addresses: When creating a new journal entry, clearing the date field causes an error because the system tries to compute the placeholder name field using the date, which is missing. Current behavior before PR: An error is raised when the date field is cleared while creating a journal entry, as the computation of the name field relies on the date field being present. Desired behavior after PR is merged: The system will check if the date field is
Original PR description
Description of the issue/feature this PR addresses: When creating a new journal entry, clearing the date field causes an error because the system tries to compute the placeholder name field using the date, which is missing. Current behavior before PR: An error is raised when the date field is cleared while creating a journal entry, as the computation of the name field relies on the date field being present. Desired behavior after PR is merged: The system will check if the date field is present before computing the name field. If the date field is missing, a default value will be used, or a clear validation error will be displayed to the user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#204679
Previously, POL did not have a `discount` field which meant that the `discount` of a SOL was transferred in the `price_unit` of the POL. For example, the following SO: Product | Unit Price | Discount | Tax Excl. ------------|------------|----------|---------- Product A | $1000.0 | 10.0% | $900.0 Would be converted into the following PO Product | Unit Price | Tax Excl. ------------|------------|---------- Product A | $900.0 | $900.0 However, as of V17, it
Original PR description
Previously, POL did not have a `discount` field which meant that the `discount` of a SOL was transferred in the `price_unit` of the POL. For example, the following SO: Product | Unit Price | Discount | Tax Excl. ------------|------------|----------|---------- Product A | $1000.0 | 10.0% | $900.0 Would be converted into the following PO Product | Unit Price | Tax Excl. ------------|------------|---------- Product A | $900.0 | $900.0 However, as of V17, it is possible to add discount on POL, but are not taken into account when converting into SOL. With this commit, the discounts are now synchronized when going from SOL->POL and inversely. opw-4446288 Forward-Port-Of: odoo/enterprise#82676 Forward-Port-Of: odoo/enterprise#82079
When the order is sent to the preparation tools, synchronization is performed twice. This is because synchronization is done in the preparation tool method and in the unsetTable method. taskId: 4664549 Forward-Port-Of: odoo/enterprise#82286
Original PR description
When the order is sent to the preparation tools, synchronization is performed twice. This is because synchronization is done in the preparation tool method and in the unsetTable method. taskId: 4664549 Forward-Port-Of: odoo/enterprise#82286
If an order is send to the preparation display from a retail shop `false` was shown as card name. This was because `floating_order_name` is not used in retail shops. New behavior from retail shop: - Order card name is `tracking_number (pos_reference)` New behavior from restaurant: - Order card name is `floating_order_name` or `Direct Sale` or `table_number`. taskId: 4711882 Forward-Port-Of: odoo/enterprise#83028
Original PR description
If an order is send to the preparation display from a retail shop `false` was shown as card name. This was because `floating_order_name` is not used in retail shops. New behavior from retail shop: - Order card name is `tracking_number (pos_reference)` New behavior from restaurant: - Order card name is `floating_order_name` or `Direct Sale` or `table_number`. taskId: 4711882 Forward-Port-Of: odoo/enterprise#83028
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user having another company : base.demo_company_fr This creates the following error message when running the tests: ```Py FAIL: TestDocumentsControllers.test_upload_internal_multi_company_defaults Traceback (most recent call last): File "/home/odoo/src/enterprise/documents/tests/test_controllers.p
Original PR description
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user…
test_upload_internal_multi_company_defaults was added in commit 9f66204e0cd0b2f19456f3bb0131d23e6d137b0b (PR #80060) but for databases with l10n_fr_account installed, the test fails due to the user having another company : base.demo_company_fr
This creates the following error message when running the tests:
```Py
FAIL: TestDocumentsControllers.test_upload_internal_multi_company_defaults
Traceback (most recent call last):
File "/home/odoo/src/enterprise/documents/tests/test_controllers.py", line 953, in test_upload_internal_multi_company_defaults
self.assertEqual(self.user_admin.company_ids, main_company | comp)
AssertionError: res.company(28, 1, 110) != res.company(1, 110)
```
with the following command :
```bash
python3 odoo-bin --addons-path="addons/,../enterprise/" -d test_4507424 -i documents,accountant,l10n_fr_account --test-tags .test_upload_internal_multi_company_defaults
```
(make sure to use the correct python3, odoo-bin, and addons-path)
This commit fixes the test by removing the constraint that self.user_admin can only have 2 companies
After this commit, the test is successful with the same configuration and execution command
opw-4700255
opw-4507424
Forward-Port-Of: odoo/enterprise#82869Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These of
Original PR description
Following commit 6b5acdde9998fb1ee0d4d4aee0ab2375e50d7703 we ensured that we stopped the stock synchronization when there was a discrepancy between an offer fulfilment channel and an order fulfilment channel. This bugfix didn't consider the cases of offers that were synced once then never updated with the changes of the new API, thus not being the string of a dictionary, but instead, being the string of an int. Thus raising an attribute error, and not a JSON error nor a TypeError. These offers, though, don't need that safety net, and can thus just be ignored. If their stock needs to be sync someday, the stock cron will take care of these. opw-4684657 opw-4684605 Forward-Port-Of: odoo/enterprise#83023
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347
Original PR description
Before this commit: Multi-package delivery validation for the carrier 'loomis' results in an error. Rate is calcuated in the first request for all the packages. Response of the second request is code 201 but with a warning message of rate already calcuated for the whole shippment. Which reults in invalid operation error. After this commit: Added a check for 'LoomisExpress' to avoid the rate error from blocking validation. Multi-package delivery is validated correctly. opw-4650347 Forward-Port-Of: odoo/enterprise#82682
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
Original PR description
Purpose ======= Since: https://github.com/odoo/enterprise/commit/65b4e343ce9b16ef77f6c967314c48d0b10972bc The amounts are aggregated outside of the rule enumeration in the case there are several inputs for which the code is matching the salary rule code. But in the case the rule code is not the same as the other input code, only the last amount is retrieved, not the total amount. TaskID: 4711431 Forward-Port-Of: odoo/enterprise#83043
This PR excludes the employees that started after the 30/06 of the 13th month. They are not elligeable as they started more than 6 months before the payment of the bonus. As part of this PR, the computation of the correct tax rate has been fixed. The amount is bounded so that a tax rate can always be computed. task-4583139 Forward-Port-Of: odoo/enterprise#79923
Original PR description
This PR excludes the employees that started after the 30/06 of the 13th month. They are not elligeable as they started more than 6 months before the payment of the bonus. As part of this PR, the computation of the correct tax rate has been fixed. The amount is bounded so that a tax rate can always be computed. task-4583139 Forward-Port-Of: odoo/enterprise#79923
Steps: - Navigate to Management > Time Off > Gantt View. - Click on a pill to open the popover. Issues: - The date format in the title showed 30/10/2025 instead of 03/10/2025. - Causing inconsistency between the title and the Gantt view. Fix: Updated date formatting to ensure the title and popover both display dates are same in the MM/DD/YYYY format with leading zeros. Task - 4660785 Forward-Port-Of: odoo/enterprise#81890
Original PR description
Steps: - Navigate to Management > Time Off > Gantt View. - Click on a pill to open the popover. Issues: - The date format in the title showed 30/10/2025 instead of 03/10/2025. - Causing inconsistency between the title and the Gantt view. Fix: Updated date formatting to ensure the title and popover both display dates are same in the MM/DD/YYYY format with leading zeros. Task - 4660785 Forward-Port-Of: odoo/enterprise#81890
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this
Original PR description
Added condition on a check in microsoft calendar that ensured the organizer was an attendee on the event on create. This was added in a change that allowed the organizer to be changed on the Odoo side. However, this caused issues with the appointments app when creating an appointment that only used resources. The "organizer" who in this case is the creator of the appointment type would not be an attendee and therefore would cause an error and make the appointment type unbookable. Adding this condition allows the appointment to bypass the check if the appointment type uses resources instead of users. This change adds the necessary override in enterprise. See change in community here: https://github.com/odoo/odoo/pull/178142 opw-3841495 Forward-Port-Of: odoo/enterprise#82866 Forward-Port-Of: odoo/enterprise#69036
Forward-Port-Of: odoo/enterprise#82948
Original PR description
Forward-Port-Of: odoo/enterprise#82948
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82912 Forward-Port-Of: odoo/enterprise#81644
Original PR description
Description of the issue this commit addresses: In january 2025, updates were made to some sections of the LU tax report and chart of accounts. Therefore, the version we use is out of date. --- Desired behavior after this commit is merged: The COA and VAT reports use the new values updated in 2025. --- Community PR: https://github.com/odoo/odoo/pull/202228 task-4587067 Forward-Port-Of: odoo/enterprise#82912 Forward-Port-Of: odoo/enterprise#81644
In this commit: === - Introduced a timing filter in the preparation display to filter orders based on their scheduled time. - Added options to view All, Today, Tomorrow, and Next Days orders for better order management. related-https://github.com/odoo/odoo/pull/196122 task-4523422 Forward-Port-Of: odoo/enterprise#78345
Original PR description
In this commit: === - Introduced a timing filter in the preparation display to filter orders based on their scheduled time. - Added options to view All, Today, Tomorrow, and Next Days orders for better order management. related-https://github.com/odoo/odoo/pull/196122 task-4523422 Forward-Port-Of: odoo/enterprise#78345
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/203713 --- I confirm I have signed
Original PR description
## Pull Request HOOT (PRHOOT) 30 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Community: https://github.com/odoo/odoo/pull/203713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#82999 Forward-Port-Of: odoo/enterprise#82351
Forward-Port-Of: odoo/enterprise#83047
Original PR description
Forward-Port-Of: odoo/enterprise#83047
account_intrastat_report.xml: missing SUCode for xml report generation in l10n_de_intrastat build_error-160011 Forward-Port-Of: odoo/enterprise#81066
Original PR description
account_intrastat_report.xml: missing SUCode for xml report generation in l10n_de_intrastat build_error-160011 Forward-Port-Of: odoo/enterprise#81066
See community PR odoo/odoo#204757 for the bugfix. This commit adds a step to the scale tour to check that the computed price in the popup matches the expected value. The tour is also refactored slightly to make use of POS test helpers. task-4702650 Forward-Port-Of: odoo/enterprise#82873
Original PR description
See community PR odoo/odoo#204757 for the bugfix. This commit adds a step to the scale tour to check that the computed price in the popup matches the expected value. The tour is also refactored slightly to make use of POS test helpers. task-4702650 Forward-Port-Of: odoo/enterprise#82873
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692
Original PR description
Some keys were not correclty translated Steps to reproduce: ------------------- * Install l10n_pe_reports_stock * Switch to PE Company and Spanish language * In Stock create a new operation * Open the dropdown Type of Operation (PE) > Observation: Why the fix: ------------ Based on official values https://www.sunat.gob.pe/legislacion/superin/2015/anexo3-rs169-2015.pdf Tabla 12 opw-4653572 Forward-Port-Of: odoo/enterprise#82692