Daily updates from Odoo
Navigate
Branch
Friday, August 23, 2024
63 changes
24 changes
Enhancements to existing features
This update improves Odoo's internal Hoot testing framework, making automated tests more accurate, easier to diagnose, and faster to use. It helps developers catch issues earlier and reduces the risk of unstable test results without changing business features for end users.
Original PR description
## Pull Request HOOT (PRHOOT) - part 22 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PRHOOT) - part 22 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971 Part 15.5: https://github.com/odoo/odoo/pull/166463 Part 16: https://github.com/odoo/odoo/pull/166311 Part 17: https://github.com/odoo/odoo/pull/168328 Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657 Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767 Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895 Part 21: https://github.com/odoo/odoo/pull/174337 Enterprise: https://github.com/odoo/enterprise/pull/68721 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. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The task portal now avoids sending users to empty timesheet pages when they do not have permission to view any related timesheets. It also checks timesheets across all levels of subtasks, making the link behavior clearer and reducing confusion for limited-access users.
Original PR description
Currently, when a user has a limited access to timesheets, it is possible that he has access to a task, but that he has no access to the timesheets of its children task. This make a strange use case where the user clicks on the link to be redirected to a page without any timesheet. This fix aims to change that. Solution : change the link to the timesheets into a span if none of the timesheets are accessible by the current user. task - 3978484 version saas-17.2 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 lot numbers entered in detailed stock operations could disappear after switching between receipt lines. Warehouse users can now enter lot details across multiple products without losing information, improving receipt accuracy and reducing rework.
Original PR description
### Steps to reproduce - Create 2 products tracked by Lots - Create and "mark as to do" a receipt with two lines: - 1 x Product 1 - 1 x Product 2 - Click on the list icon (details Operation) of the…
### Steps to reproduce - Create 2 products tracked by Lots - Create and "mark as to do" a receipt with two lines: - 1 x Product 1 - 1 x Product 2 - Click on the list icon (details Operation) of the first line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line - Add a Lot name to the line and save (on the Open stock move dialog) - Click on the list icon (details Operation) of the second line #### > the lot_name has not been saved ### Cause of the issue When calling openRecord, if the parent of the record is dirty (the picking), it is saved and reload before proceeding: https://github.com/odoo/odoo/blob/709ad381120ab7a7b9ff14ec473b410a53f39e28/addons/stock/static/src/views/picking_form/stock_move_one2many.js#L49-L54 This is what happens when you open the second line since you changed the content of the first line. However, when we proceed with this called, the `super.openRecord` will be called on the record on which we started the call with rather than the corresponding record of the reload. So that its change will not be saved. ### Solution: A similar issue has already been solved by commit 127e735 and the same fix can be used by restructuring the code + it allows to reload the record only once. opw-4097653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing orders now calculate finished product unit costs correctly when worker and work center time costs are involved. This prevents inflated production costs in the manufacturing overview and helps keep inventory valuation accurate.
Original PR description
**Steps to reproduce the bug:**
- Create two workers:
- Worker 1: Hourly Cost = $10
- Worker 2: Hourly Cost = $6.30
- Create a work center:
- Cost per hour: $6.66
- Create a storable product “P1”:
- Component: “C1”, cost: $1.02
- Create a manufacturing order (MO):
- Product: 1 unit of P1
- Confirm the MO
- Go to the operation and open the work order:
- Add two time tracking entries for the same date:
- Worker 1: 29/05/2024 - 08:00
- Worker 2: 29/05/2024 - 08:00
- Validate the MO
- Go to the MO overview
**Problem:**
The unit cost is $30.64 instead of $23.98
opw-3934566Miscellaneous changes
Updates the tax label and description translations in order to better fit the market. Task id # 4069669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176258
Original PR description
Updates the tax label and description translations in order to better fit the market. Task id # 4069669 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176258
**Steps to reproduce:** - Create an empty db - Go to the configuration of the company - Set the country of the company to Bangladesh - Install Accounting **1st issue:** The localization module (i.e. l10n_bd) has not been installed. [Same issue with: l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug] - Go to Accounting settings - Select "
Original PR description
**Steps to reproduce:** - Create an empty db - Go to the configuration of the company - Set the country of the company to Bangladesh - Install Accounting **1st issue:** The localization module (i.e.…
**Steps to reproduce:**
- Create an empty db
- Go to the configuration of the company
- Set the country of the company to Bangladesh
- Install Accounting
**1st issue:**
The localization module (i.e. l10n_bd) has not been installed.
[Same issue with:
l10n_bd, l10n_bf, l10n_bj, l10n_cd, l10n_cf, l10n_cg, l10n_ci, l10n_cm, l10n_cy, l10n_ga, l10n_gn, l10n_gq, l10n_gw, l10n_km, l10n_ml, l10n_mt, l10n_ne, l10n_rw, l10n_sn, l10n_td, l10n_tg, l10n_ug]
- Go to Accounting settings
- Select "Bangladesh" as Fiscal Localization
- Save the settings
**2nd issue:**
A KeyError is raised:
File "/home/odoo/src/17_1/odoo/odoo/fields.py", line 1362, in compute_value
fields = records.pool.field_computed[self]
KeyError: 'account.asset.currency_id'
**Cause:**
**1st issue:**
"auto_install" is not present in the manifest file.
**2nd issue:**
When loading the chart template in "_load" method, "pool" attribute of "company" and "self" is not the same after the creation of a new registry. And [company = company.with_env(self.env)] does not update company.pool Therefore, when executing [self._pre_reload_data(company, template_data, data)], "self" and "company" are not on the same registry.
**Solution:**
**1st issue:**
Add 'auto_install': ['account'] in the manifest as it is done in others localization modules.
**2nd issue:**
Browse the company instead of using "with_env(self.env)" to update "company.pool".
opw-4119423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#177254Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points: - bus service to worker to start it - bus service to worker to initialize it - worker to bus service to acknowledge the initialization - bus service to worker to add the channel The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. Thi
Original PR description
Before this PR, the `receive notifications from a channel` test was sometimes failing. This test waits for the channel to be registered before sending the notification. This flow has many async points: - bus service to worker to start it - bus service to worker to initialize it - worker to bus service to acknowledge the initialization - bus service to worker to add the channel The `waitUntilSubscribe` helper waits up to 500ms, but when runbot is heavily used, it can take a bit longer. This PR increases the delay to ensure the flow can complete within the given time. runbot-75076 Forward-Port-Of: odoo/odoo#177530
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user. This results in a situation in which the user initiating the question Before this commit: It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some valu
Original PR description
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so,…
The aim of this commit is to ensure we always have a company from which to pull values. Context: On odoo.com, we have only one website but when users buy something on our website, we create the so, the payment and the invoice with the company which is in the country of the user. This results in a situation in which the user initiating the question Before this commit: It was possible to not have a company there, leading to inconsistencies later on when relying on company to get some values like `tax_calculation_rounding_method`. For odoo.com, it resulted in a 0.01€ discrepancie between the sale order and its invoice. As the payment transaction was made based on the sale order amount, the invoice remained unpaid forcing the accountants to manually write off the difference. After this commit: There is always a default company provided ensuring taxes gets computed correctly and thus having sale order and invoice having the same amount. Special thanks to PMO for his HUGE help debugging this madness. task-id: None (issue spotted on odoo.com) Forward-Port-Of: odoo/odoo#177618
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-
Original PR description
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-4053187 Enterprise PR: odoo/enterprise#67621 Forward-Port-Of: odoo/odoo#175002
Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable. This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong comp
Original PR description
Following introduction of the new relational model in 8723f020c358, when an onchange is triggered from a field of a one2many, we were only sending parent's fields that are editable. This cause some issue when the user first trigger a change in the parent record that update some readonly fields (ex. computed fields), then trigger an onchange from one of the one2many fields; in that scenario the onchange will miss the updated readonly fields values from the parent; this can lead to wrong computation of the onchange result. This commit send the values from parent readonly fields that have been modified (and with this align with server-side implementation behavior from `odoo.tests.form.Form`) opw-3941571 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177399
Set up email alias for Vendor Bill journal Send email with xls attachment to alias Bill is created Issue: No attachment is present This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c the system will not add binary attachments to the created bill The change was meant to filter out rogue images often present in emails but it is too restrictive so this commit add a second check with the mimetype of the parsed attachment in order to keep u
Original PR description
Set up email alias for Vendor Bill journal Send email with xls attachment to alias Bill is created Issue: No attachment is present This occurs because after https://github.com/odoo/odoo/commit/9b735f7597d75412a8ea6c4e541b05eb8849bd9c the system will not add binary attachments to the created bill The change was meant to filter out rogue images often present in emails but it is too restrictive so this commit add a second check with the mimetype of the parsed attachment in order to keep useful attachments opw-4092311 Forward-Port-Of: odoo/odoo#176004
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
Original PR description
1) Start creating a tax 2) Set the 'Tax Computation' to 'Group of taxes' 3) In 'Definition' tab, select 'Add a line', choose to create a new tax 4) Jumpt to 2 Issue: Nested group of taxes are not allowed When adding the child tax users cannot choose group of taxes, but we can't block creation of just a specific type of taxes so we need to check the type afterward opw-4060955 Forward-Port-Of: odoo/odoo#176359 Forward-Port-Of: odoo/odoo#173889
This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs: **Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+. **Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards. **Fixes:** - This PR fixes Bug 2 in version 15.0, ensuring the correct
Original PR description
This PR addresses issues with the custom amount selection on the `/donation/pay` page, which has been present since version 15.0. Users have experienced confusion about the actual donation amount due to the following bugs: **Bug 1:** Multiple amounts could be selected simultaneously, affecting versions 17+. **Bug 2:** The last selected amount was not the actual amount donated, affecting all versions from 15 onwards. **Fixes:** - This PR fixes Bug 2 in version 15.0, ensuring the correct amount is selected and donated. - During the forward-port to version 17.0, we will also address Bug 1. The fix in version 17.0 will involve changes to the `payment_form.js` file, as the relevant file is no longer in use. The new solution will be cleaner and will not rely on `.o_wpayment_fee_impact`. task-4115678 Forward-Port-Of: odoo/odoo#177270 Forward-Port-Of: odoo/odoo#176722
FixImp, I often add such url assertions with bugfixes, I wanna use this new function with them Testing that we are correctly redirected to a specific URL is something recurrent in both the http framework and website. There are various competiting ways to achieve this. In this work we propose a single go-to function that (1) takes care of sanitizing both URLs to deal with missing scheme/host and (2) ouput a nice assertion message when the urls are different. It uses urllib3 because it pa
Original PR description
FixImp, I often add such url assertions with bugfixes, I wanna use this new function with them Testing that we are correctly redirected to a specific URL is something recurrent in both the http framework and website. There are various competiting ways to achieve this. In this work we propose a single go-to function that (1) takes care of sanitizing both URLs to deal with missing scheme/host and (2) ouput a nice assertion message when the urls are different. It uses urllib3 because it parses "example.com" as `netloc="example.com"` instead of urllib that parses it as `path="example.com"`. 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#177005 Forward-Port-Of: odoo/odoo#176763
Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS. Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future. Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053 Forward
Original PR description
Refactoring method _check_peppol_endpoint_number and _sanitize_peppol_endpoint. Added sanitization for current supported EAS. This refactoring will make it easier to add support for more EAS. Refactoring to solve issues with wrong handling of Peppol ID and make it easier to add better support for more EAS without large modifications. This will also make the code easier to support in the future. Original Discussion: https://github.com/odoo/odoo/pull/176109#issuecomment-2286587053 Forward-Port-Of: odoo/odoo#176651
Problem --------- With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem: when reversing an invoice, the current company is used as recipient bank and not the customer's one. However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that. When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank. opw-4035448 --- I
Original PR description
Problem --------- With commit c1ea29ea79ad074aae750d26496fc6ce22cffb54, we fixed the following problem: when reversing an invoice, the current company is used as recipient bank and not the customer's one. However, that fix did only took into concideration reversing invoices and not bills. This commit is here to fix that. When reversing a BILL (in_invoice), we use the company's bank. When reversing an INVOICE (out_invoice), we use the commercial partner's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177023
### Steps to reproduce: - Install Inventory module - Create a move from any operation - Save this move and keep the reference > Change the operation type and save again - Navigate to Moves History - Search for the move with the old reference ### Current behavior before PR: The move will be shown in the moves history with the old reference. This is happening because when changing the opertaion type it doesn't trigger the compute of the reference. https://github.com/odoo/odoo/blob/17
Original PR description
### Steps to reproduce: - Install Inventory module - Create a move from any operation - Save this move and keep the reference > Change the operation type and save again - Navigate to Moves History - Search for the move with the old reference ### Current behavior before PR: The move will be shown in the moves history with the old reference. This is happening because when changing the opertaion type it doesn't trigger the compute of the reference. https://github.com/odoo/odoo/blob/17.0/addons/stock/models/stock_move.py#L265 ### Desired behavior after PR is merged: We added the picking_id.name as a dependant field for the reference so when it is changed the computation method of the reference will be triggered to update the reference. opw-4062591 Forward-Port-Of: odoo/odoo#174398
When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page. This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow. opw-4050389 Forward-Port-Of: odoo/odoo#177436 Forward-Port-Of: odoo/odoo#177207
Original PR description
When having a lot of forum posts, the pager can display up to 10 pages, because the specified scope is the set to the same value as the number of posts per page, which is 10. This causes layout issues in mobile view in that case, because the pager overflows from the page. This commit fixes that by setting the scope to 5 instead (like the Event pager), which is just enough to not overflow. opw-4050389 Forward-Port-Of: odoo/odoo#177436 Forward-Port-Of: odoo/odoo#177207
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory. However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the fi
Original PR description
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file…
From most openpyxl resources it is generally recommended to instantiate it as `read_only=True` or `write_only=True` in order to leverage lazy modes which do not need to eagerly load the entire file in memory.
However this causes memory exhaustion issues in Odoo workers, with file preview / imports failing: apparently we have managed to generate the `res_partner.xlsx` sample file in such a way that `load_workbook(read_only=True)` is incapable of finding the end of the file, so it thinks the file goes up to the limit for the format of 1048576 rows:
$ python -c 'import openpyxl; w = openpyxl.load_workbook("odoo/addons/base/static/xls/res_partner.xlsx", data_only=True, read_only=True); print(sum(1 for _ in w.worksheets[0]))'
1048576
even though the file only has 4 rows (including the header).
This means any client which uses this file as basis to create their own export (or a method generating similarly odd / corrupted files) requires parsing on the order of 20~30 million cells to try and import the file, even though in reality they might only have a few dozens or hundreds.
As a result the import *attempt* takes several minutes (4~5 locally, maybe a bit less on beefy server) and ~1.7GB memory, and thus routinely fails if the worker has any sort of existing pressure (e.g. well filled caches) as it hits the hard memory limit (2.5G by default).
Using the "less efficient" standard mode, the ingestion takes ~1.4s and 14.5MB memory. Which is still a far cry less efficient than xlrd.xlsx was (~0.00 seconds and 120k) but at least somewhat reasonable...
The issue has been reported upstream at https://foss.heptapod.net/openpyxl/openpyxl/-/issues/2221
Forward-Port-Of: odoo/odoo#177586Add text editor write mode aliases. Forward-Port-Of: odoo/odoo#176974
Original PR description
Add text editor write mode aliases. Forward-Port-Of: odoo/odoo#176974
# Description With the upgrade to Chart.js version 4.3, the configuration for setting legend label colors has changed. The `fontColor` key is now deprecated, and the `color` key must be used instead. This update was previously overlooked in the Odoo chart plugin. This commit resolves the issue by updating the Odoo chart plugin to correctly use the color key for setting legend label colors. Task: [4111089](https://www.odoo.com/odoo/project/2328/tasks/4111089) --- I confirm I ha
Original PR description
# Description With the upgrade to Chart.js version 4.3, the configuration for setting legend label colors has changed. The `fontColor` key is now deprecated, and the `color` key must be used instead. This update was previously overlooked in the Odoo chart plugin. This commit resolves the issue by updating the Odoo chart plugin to correctly use the color key for setting legend label colors. Task: [4111089](https://www.odoo.com/odoo/project/2328/tasks/4111089) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177420
Example of steps: - install `inventory` - Open a transfer/receipts - add a product - validate it - click on return - there is a modal with the product - double click quickly on remove button - click return - traceback ``` psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12" LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
Original PR description
Example of steps: - install `inventory` - Open a transfer/receipts - add a product - validate it - click on return - there is a modal with the product - double click quickly on remove button - click…
Example of steps:
- install `inventory`
- Open a transfer/receipts
- add a product
- validate it
- click on return
- there is a modal with the product
- double click quickly on remove button
- click return
- traceback
```
psycopg2.errors.InvalidTextRepresentation: invalid input syntax for type integer: "virtual_12"
LINE 1: ...ETE FROM "stock_return_picking_line" WHERE id IN ('virtual_1...
^
```
When this modal is opened, a `one2many` is built with “virtual” records,
which are the products selected in the transfer.
These records are virtual because we don't know which ones the customer
will keep - we'll only know for sure when he clicks on “Return”.
So, when this o2m is loaded, the setup of the Record class populates it.
A first call to the `_applyCommands` function is made with a command to
create a record (product) (command 0/CREATE).
Once the o2m has been loaded, the customer (who quickly clicks to remove
several products) ends up at some point double-clicking on the remove
button of the same product will trigger two consecutive calls to `_applyCommands`.
The first call (which is the correct call)
will have the command: `[2, “virtual_12”]` which is a `DELETE`.
But as we've already asked to create the same “virtual_12” record,
we are here:
https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L580-L585
Here, given that we have a delete `virtual_12` command and that just before
the setup we asked to create `virtual_12`, this condition will just remove
the command that creates `virtual_12` to simplify the operation without
creating a `DELETE` command.
So instead of creating it and then deleting it, we just don't create it.
The problem arises with the second click, which triggers exactly the same
call to `_applyCommands`, asking to delete `virtual_12`.
As this time we don't have any more “record creation” pending, we'll
enter here
https://github.com/odoo/odoo/blob/7caddbb653aa8235725b48ff9f28d6119fdc3567/addons/web/static/src/model/relational_model/static_list.js#L583-L585
The second click will ask you to delete a record that never existed in
the `web_save`... so that's what the python server don't like!
To correct the problem, I apply a variable to the button in the dom,
which I set to true when the first click occurs, and which I check on
the second click to ignore it.
opw-[4043992](https://www.odoo.com/web#id=4043992&view_type=form&model=project.task)
Forward-Port-Of: odoo/odoo#173481Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177332
Original PR description
Some spelling mistakes were forgotten in a previous pull request that meant to add constraints on carryover See https://github.com/odoo/odoo/pull/177064#pullrequestreview-2248102992 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#177332
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it. This commit fixes this issue by adding more freedom to these mega
Original PR description
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force…
The "Images Subtitles" and the "Thumbnails" mega menu templates do not look good in mobile view, depending on the size of the text written in them. Indeed, under some breakpoints, the classes force the elements to be next to each to other, to have two elements by line. So if a big word is contained in the left one, which is not rare in the German language for example, the text may overflow to the right one and overlap with it. This commit fixes this issue by adding more freedom to these mega menu templates at the problematic breakpoints, so they can be more responsive with their content, while still looking good. Step to reproduce: - In the menu editor, add a mega menu. - In edit mode, click on the mega menu. - Select the "Images Subtitles" or the "Thumbnails" template. - As a first element, write the following title: "Foto- und Fine Art Großformatdrucker". - Save and resize down the screen until it toggles the mobile view. - Open the mega menu and continue to resize down. => At some point, near the "SM" breakpoint, you will notice that the text becomes too big and overlaps the right element. opw-4096112 Forward-Port-Of: odoo/odoo#177103
26 changes
New functionality added to Odoo
The Pricer module can now mark specific products as promotional based on a selected pricelist. This helps stores display promotion information directly on Pricer tags, making special offers clearer for customers and staff.
Original PR description
Added sale logic to pricer module. Community PR: [https://github.com/odoo/odoo/pull/172491](https://github.com/odoo/odoo/pull/172491) Task: 3607937
Enhancements to existing features
This update removes reliance on an older database query helper across several reporting and data cleanup areas. It keeps payroll, recruitment, planning, timesheet forecasting, and data cleaning reports aligned with the main platform’s database practices, reducing maintenance risk without changing day-to-day user workflows.
Original PR description
odoo/odoo#173992
This update adds automated test coverage for reacting to WhatsApp messages. It helps ensure upcoming WhatsApp messaging improvements work reliably before they reach users.
Original PR description
Preparation for PR odoo/odoo#170553
Users can now change the sorting of spreadsheet list data directly from the list side panel. The spreadsheet view updates immediately, making it easier to organize and review list information without leaving the current workflow.
Original PR description
### [IMP] spreadsheet_edition: add edit list sorting feature in list side panel This commit implements a feature for changing the list sorting directly in the side panel with a real-time update of the user interface. Task: [3636092](https://www.odoo.com/odoo/project/2328/tasks/3636092)
The manufacturing planning screen now orders related items more reliably, including complex products with several bill of materials levels. Opening planning from a bill of materials now shows all related child items, helping teams get a fuller view of demand and dependencies without extra navigation.
Original PR description
This PR contains the following commits: - improve the sequence calculation - see all the children MPS when opening from a specific bom and not just the first level task-4033339
This update adjusts website sales and rental test tours to use the latest shared testing utility structure. It is an internal quality improvement that helps keep automated checks maintainable without changing customer-facing behavior.
This update improves how translated messages are built across multiple Odoo Enterprise apps, reducing cases where parts of messages could stay untranslated or appear in an unnatural word order. This helps deliver clearer, more accurate wording for users working in languages other than English.
Original PR description
There are many places in the code where translated strings are concatenated to other strings, translated or untranslated. While it is sometimes the right thing to do, there are also a lot of problematic cases: - When concatenating untranslated strings, it obviously means they won't be translated, even though they sometimes should be - Even if they don't need to be, the order of words can vary greatly between languages, and including it makes reordering easier. - The same issue can arise when concatenating multiple translated strings, especially if they are part of one sentence. This commit fixes the problematic occurrences of concatenation. It also adds some named placeholders and uses of the `format_list` helper. Community: https://github.com/odoo/odoo/pull/171425 Task-3997249
Resolved issues and error corrections
Accounting report titles now match their updated menu names, avoiding confusion for users navigating reports. PDF exports also include proper side margins so report content no longer runs to the edge of the page.
Original PR description
In this commit: https://githu.com/odoo/enterprise/pull/67611/commits/982eaa3867576f581e5f12fa649a281d9407278b We renamed some reports menu item but we didn't change the name on top of the ui of the reports so there was a discordance. Before this commit the side of the pdf were extended to the side of the page. To resolve that issue adding a margin on the content of the pdf is enough. task: 4127269
The field service worksheet setup test now waits until the template window has fully closed before continuing. This reduces false failures in automated checks and helps keep the feature validation more reliable.
Original PR description
Before this commit, when the step on the `fsm_task_form_tour` tour saves the worksheet template creation, the save action will take some times to be able to generate a new worksheet model for that worksheet template. The problem is the tour does not wait enough time before doing the next steps. This commit adds a step to wait the form view dialog of the worksheet template is closed before doing the other steps. runbot-72641
The restaurant appointment screen now shows the correct booking icon again. This fixes a visual mistake from a previous change, helping staff recognize booking actions more easily.
Original PR description
In commit ed556a111ead0c9a1fe517173cc97c495d0d6ac7 the booking icon was replaced by mistaked. In this commit we revert to the original one.
This fixes an automated test that could fail because it clicked a pager button before it was ready. The change makes the test wait until the button is enabled, improving test reliability without changing user-facing behavior.
Original PR description
The tour changes the number of elements in the pager. We then check that the number of elements do change in the list. But the button stay disabled longer, which implies that we try to click on it too soon in the tour, failing it. We should wait for the button to be enabled before clicking on it. runbot-74835
Miscellaneous changes
Steps to reproduce: - Open Project app. - Go to all tasks/my tasks - Change view to gantt Issue: - You can observe that there is no visual effect(grey cell)for unavailability i.e, company holidays / timeoff. Reason: - The method ```_gantt_unavailability``` in ```project_task``` of ```project_enterprise``` is not having a sync on how it is providing the values - Technically speaking here the structure of data being sent is not compatible with extracting the unavailability maki
Original PR description
Steps to reproduce: - Open Project app. - Go to all tasks/my tasks - Change view to gantt Issue: - You can observe that there is no visual effect(grey cell)for unavailability i.e, company holidays /…
Steps to reproduce:
- Open Project app.
- Go to all tasks/my tasks
- Change view to gantt
Issue:
- You can observe that there is no visual effect(grey cell)for unavailability i.e, company holidays / timeoff.
Reason:
- The method ```_gantt_unavailability``` in ```project_task``` of ```project_enterprise``` is not having a sync on how it is providing the values
- Technically speaking here the structure of data being sent is not compatible with extracting the unavailability making them ignored.
The structure being sent is something like this
```{ 'unavailabilities': [intervals]}``` -- This wrong
```{user_id: [intervals]}, {user_id: [intervals]}``` -- something like this required
The current data being sent is getting overriden everytime it goes into the loop
Also we don't specify the users and their intervals.
Fix:
- Adapting the code to the above problems mentioned.
Affected from commit - https://github.com/odoo/enterprise/commit/c6ae9f78f88322d1074700ba6923162059dba42c
task-4063237
Forward-Port-Of: odoo/enterprise#67114## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues. This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config: ``` _computeDataContext() { ... const data = toRaw(this.data); for (const fieldName in data) { const value = data
Original PR description
## Analysis Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid…
## Analysis
Since a recent commit (https://github.com/odoo/enterprise/commit/25f72c0b716d5fdc15493b74375106e3d6f580fa), the operation_note is fetched independently from the other fields to avoid performance issues.
This causes issues as, when computing data context (e.g. during `onChange`), we assume that all fields in data are available in config:
```
_computeDataContext() {
...
const data = toRaw(this.data);
for (const fieldName in data) {
const value = data[fieldName];
const field = this.fields[fieldName]; // field == undefined
if (field.relatedPropertyField) { // traceback
continue;
}
...
}
```
## Steps to reproduce
- Create a product "TEST"
- Create a BoM For product "TEST", with a new product "TEST Component".
- Add 1 Operation OP1 (keep default value), set a description
- Add 1 step to OP1, with type "Register Production"
- Create MO for "TEST", Confirm, Plan,
- Start operation OP1
- On ShopFloor, go to MO, select workcenter, open step
- Update quantity: Error
## Solution
We make a way for manually fetched fields (most probably, all HTML fields which can contain base64 images) and add it to the fields to avoid them being undefined and causing tracebacks.
## References
opw-4103712
--
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Forward-Port-Of: odoo/enterprise#68497Before this commit, when the helpdesk ticket is created by the website form and need to insert an attachment, the subtype used is altered to be able to let the portal user to see it instead of a using a non internal subtype. This commit reverts the changes made in d9b06557baf692f707ff8b75106df6b67c6bc523 to avoid altering the subtype. Forward-Port-Of: odoo/enterprise#68771
Original PR description
Before this commit, when the helpdesk ticket is created by the website form and need to insert an attachment, the subtype used is altered to be able to let the portal user to see it instead of a using a non internal subtype. This commit reverts the changes made in d9b06557baf692f707ff8b75106df6b67c6bc523 to avoid altering the subtype. Forward-Port-Of: odoo/enterprise#68771
If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket). Forward-Port-Of: odoo/enterprise#68719
Original PR description
If longpolling fails, it displays a fail popup with help messages. We added a `fallback` parameter allowing to prevent this popup from displaying if we want to fallback on other methods (e.g. websocket). Forward-Port-Of: odoo/enterprise#68719
…bill Forward-Port-Of: odoo/enterprise#66846
Original PR description
…bill Forward-Port-Of: odoo/enterprise#66846
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-
Original PR description
Currently, receipts are not take into account when generating the VAT Record books ### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * enable sales (or purchase) receipts in the settings * create and confirm a sales receipt * open the generic tax report * select the dates for the receipt. * attempt to generate the VAT Record books You will be met with a traceback. ### Fix Include receipts and treat them as invoices. (confirmed with JCO) opw-4053187 Comunity PR: odoo/odoo#175002 Forward-Port-Of: odoo/enterprise#68804 Forward-Port-Of: odoo/enterprise#67621
Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner st
Original PR description
Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner starts to accumulate as all the partner with missing info will be processed daily without further notice This commit introduce the following mitigations for the issue: - Update the next remainder date even if no message has been sent - Limit the number of partner we process per run to 1000 - Add a message to the partner record in case the followup action failed opw-3935084 Forward-Port-Of: odoo/enterprise#68615 Forward-Port-Of: odoo/enterprise#66770
Add a new module that supports printing to the Philippine check format Task id # 3576570 Forward-Port-Of: odoo/enterprise#56117
Original PR description
Add a new module that supports printing to the Philippine check format Task id # 3576570 Forward-Port-Of: odoo/enterprise#56117
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#68652 Forward-Port-Of: odoo/enterprise#65897
Original PR description
Commit fixes appointment description styling task-3446959 Forward-Port-Of: odoo/enterprise#68652 Forward-Port-Of: odoo/enterprise#65897
This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#68495 Forward-Port-Of: odoo/enterprise#64260
Original PR description
This will add rules for the "Crédit d'impôt salarié" and for the "Crédit d'Impôt pour Compensation taxe Carbone" to the Luxembourg loca. Task: 3970107 Forward-Port-Of: odoo/enterprise#68495 Forward-Port-Of: odoo/enterprise#64260
Steps to reproduce: - Create a project and a task - Attach a file to the task - Share the task with Joel Willis (portal user) - DO NOT share the project with him - Log in as Joel Willis (portal user) - Click Tasks > '1 Document' button next to project name This redirects back to portal home menu. This happens because the button leads to projects/id/documents, which Joel Willis has not been granted access to. The expectation would be a redirection to tasks/id/documents instead, as por
Original PR description
Steps to reproduce: - Create a project and a task - Attach a file to the task - Share the task with Joel Willis (portal user) - DO NOT share the project with him - Log in as Joel Willis (portal user) - Click Tasks > '1 Document' button next to project name This redirects back to portal home menu. This happens because the button leads to projects/id/documents, which Joel Willis has not been granted access to. The expectation would be a redirection to tasks/id/documents instead, as portal > projects handles this use case, and we curently do not have a way to share documents attached to a specific task through portal. opw-4009258 Forward-Port-Of: odoo/enterprise#68720 Forward-Port-Of: odoo/enterprise#67849
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them
Original PR description
Steps to reproduce: - Create a partner with a ref "PARTNER01" - Import a FEC with the same partner ref Issue: You will 2 same contacts Cause: During the refactor, the check existing partner has been taken out https://github.com/odoo/enterprise/commit/f60263a105717a7e00b1996b2b2e7b89e514ca54#diff-0c2b1931af025d6a908eea7d818a8858c6e9b03b436757b3c49ffa9857e55ae1L208-L227 Solution: The flow has slightly changed. To make sure the records already existing have an xml_id, we update them opw-3932234 Forward-Port-Of: odoo/enterprise#68638 Forward-Port-Of: odoo/enterprise#63895
Purpose: ------- Currently, clicking several times quickly on the caret to unfold an article in the sidebar may throw an error and show the child articles several times in the sidebar. This commit fixes the issue by preventing to make a new request to load the child articles if one has already been made. Task-4099133 Forward-Port-Of: odoo/enterprise#68013
Original PR description
Purpose: ------- Currently, clicking several times quickly on the caret to unfold an article in the sidebar may throw an error and show the child articles several times in the sidebar. This commit fixes the issue by preventing to make a new request to load the child articles if one has already been made. Task-4099133 Forward-Port-Of: odoo/enterprise#68013
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68677 Forward-Port-Of: odoo/enterprise#68358
Original PR description
When auofilling towards the right the last colmn of a pivot whose column are grouped by date, we got a traceback. This was due to the fact that we were trying to use the measure string as argument of `increment_date`. Task: [4045799](https://www.odoo.com/web#id=4045799&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#68677 Forward-Port-Of: odoo/enterprise#68358
Duplicating a pricelist would copy over the price rules, but not the time-based rules. Adding copy to this field allows that to work. opw-4088788 Forward-Port-Of: odoo/enterprise#68426 Forward-Port-Of: odoo/enterprise#68066
Original PR description
Duplicating a pricelist would copy over the price rules, but not the time-based rules. Adding copy to this field allows that to work. opw-4088788 Forward-Port-Of: odoo/enterprise#68426 Forward-Port-Of: odoo/enterprise#68066
13 changes
Enhancements to existing features
Users connecting IoT devices to the database now receive clear notifications about the connection status—whether it succeeded, failed, or is still processing. This eliminates confusion and improves the user experience by providing real-time feedback instead of requiring users to manually check the connected devices list.
Original PR description
When the user was connecting an IoT to the database there was no notification or any information to tell him that he succeded / failed / had to wait to see it in the "connected" list. We now display those notifications. Task: 4104811
This update improves the performance of the Australian payroll system by optimizing how payment method information is processed. The change adjusts database query counts to ensure the system runs more efficiently when handling payroll data, which helps reduce processing time and system load.
Original PR description
This commit will increase the queryCount due to the compute on payment method added in this commit: https://github.com/odoo/odoo/pull/171795/commits/76875a28422ae5267b718b5d51bc186e9884a0e8 task: 3770458
Resolved issues and error corrections
This fix resolves a blocking issue where users couldn't generate quotes for repair orders accessed through helpdesk tickets. The problem occurred because helpdesk team information was incorrectly passed to the sales order creation process, causing validation errors. The fix prevents this context from being passed, allowing users to create quotes and manually assign sales teams as needed.
Original PR description
Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record. ### Description of the issue : 1) When generating…
Accessing a linked repair record through Helpdesk can lead to a blocking bug where the user is unable to generate a quote through the repair record. ### Description of the issue : 1) When generating a `repair.order` record through a Helpdesk ticket or accessing an existing linked repair order through the smart button, the context key for `default_team_id` will be inherited. In this case referencing the id of the current `helpdesk.team` record. 2) When trying to generate a quote through the repair order, an edge case can happen where a ValidationError is triggered at sale order creation. ``` The operation cannot be completed: another model requires the record being deleted. If possible, archive it instead. Model: Sales Order (sale.order) Constraint: sale_order_team_id_fkey ``` This is due to the fact that the `sales.order` also uses a `default_team_id` context key to designate the default sales team. If by happen stance, the referenced `id` values does not match an existing `crm.team` record, you will hit the above foreign key constraint blocking the user from generating the quote. ### Proposed fix : Functionally it makes no sense to pass the `default_team_id` context value from helpdesk to sales order, as both implicitly reference different models and functional entities. Since the `_prepare_repairs_default_value` was already introduced in https://github.com/odoo/enterprise/commit/edd88ebdcc60b7c4d261bfb8755e910356684a3f to handle the context value preparation when using the repair smart button, the simplest solution is to set the `default_team_id` context key to `False`, thus not passing it later on to the sales order (i.e. the quote will not have a default sales team, but the user can still manually define one) ### How to reproduce: 1) Set up a DB with sales, helpdesk and repairs installed 2) If using demo data, just create a handful of new helpdesk teams (`helpdesk.team`). The important part is that you have at least one record with an id that will not be present in the `crm.team` table 3) For the helpdesk team matching the above criteria, activate the Repairs option (`use_product_repairs`) in the team configuration 4) Create a helpdesk ticket for that helpdesk team, create a repair order using the action button, then try using the Create Quotation action button (`action_create_sale_order`) → Validation Error is triggered OPW-4123410
This fix resolves a test failure in the partner commission module where salespeople lacked the necessary permissions to view sale order templates. The change ensures that the sale order template field is properly visible during testing, allowing the commission plan rules test to run successfully without demo data.
Original PR description
Before this commit, the salesmen did not had the right group and the test crashed with the following error when the test was run without demo data:
```
FAIL: TestCommissions.test_commission_plan_rules_with_template
Traceback (most recent call last):
File "/data/build/enterprise/partner_commission/tests/test_commissions.py", line 221, in test_commission_plan_rules_with_template
form.sale_order_template_id = so_template
File "/data/build/odoo/odoo/tests/form.py", line 326, in __setattr__
self[field_name] = value
File "/data/build/odoo/odoo/tests/form.py", line 331, in __setitem__
assert field_info is not None, f"{field_name!r} was not found in the view"
AssertionError: 'sale_order_template_id' was not found in the view
```
runbot task: 70916 and 73195
https://runbot.odoo.com/web/#id=70916&view_type=form&model=runbot.build.error&menu_id=405&cids=1 https://runbot.odoo.com/web/#id=73195&view_type=form&model=runbot.build.error&menu_id=405&cids=1This update adds the missing French language translations for Canadian accounting financial reports that were accidentally left out in a previous update. French-speaking users in Canada will now see properly translated accounting reports instead of English text.
Original PR description
In 8f74d9d the french translation for the accounting financial reports where forgotten. This add the missing translated terms opw-4124296
This fix prevents the barcode scanner from creating unnecessary empty inventory lines when processing transfers. Previously, when a line quantity was reduced to zero, the system would still create a duplicate record with zero units. Now, zero-quantity lines are properly reset instead of being split, eliminating these superfluous records and keeping inventory transfers cleaner.
Original PR description
**Current behavior:** In Barcode, it is possible for a split of incomplete moves to be triggered which leaves the original move with a quantity and demand of zero- effectively generating a…
**Current behavior:**
In Barcode, it is possible for a split of incomplete moves to be
triggered which leaves the original move with a quantity and
demand of zero- effectively generating a superfluous record
value.
**Expected behavior:**
A split should not occur when the original line has
`quantity == 0`.
**Steps to reproduce:**
1. Create a transfer for 2 units of some product, assign it
2. Open the transfer in Barcode and use the form to add 1 unit
3. Use the back button within the Barcode app to return to the
previous action
4. Reopen the transfer, set the quantity on the move to 0 from 1
5. Use the back button to exit the transfer again
6. Open the transfer in the backend to see there is a move with
a line for 0 / 0 units.
**Cause of the issue:**
We split moves if their quantity is less than demand without
considering it may be zero.
**Fix:**
Reset the move in the case of `quantity == 0`- thus it will no
longer become a split candidate.
opw-4056241Fixed a bug that prevented users from converting helpdesk tickets to sales leads when they had more helpdesk teams than sales teams. The system was incorrectly trying to assign a helpdesk team ID to a sales lead, causing the conversion feature to fail. This fix ensures the system only assigns valid team information during the conversion process.
Original PR description
Steps to reproduce: - Helpdesk > Configuration > Helpdesk teams - Create teams until you have more help teams than sales teams - Create a ticket for the last team - Gear icon > Convert to lead - MissingError on team_id This happens because the context has default_team_id = self.id, despite these ids not being related in any way. Since this error completely blocks access to the feature we need to ensure that either the default exists or we don't pass one at all. opw-4119383
Fixed an issue where custom location settings were lost when kit bill-of-materials products were automatically broken down into their component parts during barcode scanning. Now the system properly preserves the destination location you specify, ensuring your inventory transfers go to the correct location even after the kit is decomposed.
Original PR description
**Current behavior:** When a kit bom product move line is broken down into move lines for its component products, changes written to the move line (not on the move) will not carry over to the new…
**Current behavior:**
When a kit bom product move line is broken down into move lines
for its component products, changes written to the move line
(not on the move) will not carry over to the new move nor move
lines.
**Expected behavior:**
The change should be observed beyond the decomposition.
**Steps to reproduce:**
1. Create a new internal transfer in barcode
2. Add a product with some bom via form, also edit the
destination location in the form to be something
non-default.
3. Save the form, validate the transfer
4. See that the broken down move lines don't keep the changed
destination location
**Cause of the issue:**
When the kit bom moves are exploded, the location information of
its move lines is not taken into account at any point- and thus
it's lost.
**Fix:**
For kit bom products, use a move line's location information
during creation of a move as opposed to the picking. Only link a
new move line for a kit bom product to an existing move if (in
addition to the product) the location source and destination
values match.
opw-4016702Fixed an issue where quality checks were not appearing in the order defined by the product's quality points. Quality checks are now properly sorted according to the sequence specified in the quality point configuration (per operation, per product, per quantity), ensuring users see them in the intended order during receipt inspections.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”
- Create a 3 quality.point:
- 1st per operation:
- 2nd per product
- 3rd per quantity
- Create a receipt picking with 2 unit of P1
- Mark as to do
- Try to do the “quality.check”
Problem:
The 'quality.check' is not ordered by the 'quality.point' defined in the product because the 'quality.check' measured by 'move_line' is created when the 'stock.move.line' is created before the other type, so it is proposed first.
https://github.com/odoo/enterprise/blob/fbc3ce9d690ab8c5ccf5b0f46748aec8901575a1/quality_control/models/stock_move_line.py#L31
https://github.com/odoo/enterprise/blob/fbc3ce9d690ab8c5ccf5b0f46748aec8901575a1/quality_control/models/stock_move_line.py#L54-L55
opw-3870095
Forward-Port-Of: odoo/enterprise#62047
Forward-Port-Of: odoo/enterprise#61132This fix corrects the "Certificado de Retención en IVA" (Colombian Tax Withholding Certificate) report to only include invoices that actually have withholding taxes applied. Previously, the report was incorrectly including all invoices with VAT taxes, even those without withholding taxes, resulting in inaccurate payment amounts. The fix uses a mathematical formula to accurately calculate the withholding amount based on the actual withholding tax collected.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% *…
**Steps to reproduce:** - Install Accounting and l10n_co - Switch to a Colombian company (e.g. CO Company) - Create a bill with a line having an IVA tax and a withholding tax: * IVA Compra 19% * RteIVA 15% sobre el 19% IVA - Post the bill - Create another bill with a line having only an IVA tax - Post the bill - Go to "Accounting / Reporting / Colombian Statements / Certificado de Retención en IVA" **Issue:** "Monto del Pago Sujeto Retención" column is incorrect. It takes into account the tax amount from the IVA tax of both bills. As there is no withholding tax on the second bill, it should be excluded from the report. **Cause:** The report is checking the tax lines where the account is "2408%%" to compute the amount of this column. So every tax lines with from an IVA tax will be taken into account, even if there is no wihholding tax. **Solution:** Computing the correct amount by checking the account and the presence of a withholding tax is pretty complex. It would require to rely on the invoice lines instead of the tax lines to recompute the tax amounts because the amount of a specific tax is aggregated into a unique tax line (even if there are several invoice lines with different taxes combination) and there is no information about the tax repartition in the tax line. Recomputing all from the invoice lines would bad for the performance. As the withholding taxes are always 15% over VAT in Colombian localization, we can simply apply this formula to retrieve the amount subjected to withholding: [Monto del Pago Sujeto Retención = Retenido Consignado / 15%] opw-3989661 Forward-Port-Of: odoo/enterprise#68724 Forward-Port-Of: odoo/enterprise#68016
This fix resolves a problem where payment reminders were being processed repeatedly every day without actually sending messages, causing unnecessary system load. The update ensures that reminder dates are properly updated even when no message is sent, limits the number of partners processed per cycle to 1000, and adds notification messages when reminder actions fail.
Original PR description
Accounting > Configuration > Followup Levels Open the first level, enable 'Auto Execute' Delete the remaining follow up levels Create an invoice for a partner dated in the past with payment terms 'Immediate Payment' Run manually the cron 'Account Report Followup; Execute followup' Issue: partner will be processed by the cron, a warning will be logged but the partner next remainder date has not changed, so the next day the partner will be processed again. It is an issue when partner starts to accumulate as all the partner with missing info will be processed daily without further notice This commit introduce the following mitigations for the issue: - Update the next remainder date even if no message has been sent - Limit the number of partner we process per run to 1000 - Add a message to the partner record in case the followup action failed opw-3935084 Forward-Port-Of: odoo/enterprise#68615 Forward-Port-Of: odoo/enterprise#66770
This fix prevents internal errors when displaying rental sales orders on websites with multiple companies and pricing configurations. The system now safely handles cases where sales order data may be incomplete or inconsistent, logging issues instead of crashing the website display.
Original PR description
Steps to reproduce: - Install `website_sale`, `sale_purchase_inter_company_rules` - Set the second website for "My Company (Chicago)" and as the domain put "http://2.localhost:8069/" - Create an SO on San Francisco company and save it without confirming - Execute the following SQL command: ```sql update sale_order set website_id=2, company_id=2, pricelist_id=null where id=41; -- here put the id of the SO ``` - Now open the website app and select Website 2. Issues: Internal error, this is due to the fact that we're raising a UserError here. https://github.com/odoo/odoo/blob/79ad7396b15a9e26e812f2f2151241fa5bf76e18/addons/website_sale/models/website.py#L365-L373 Since we're rendering the template we can't raise any error as such a new safe function for `sale_get_order` was made in order to just catch and log the error. opw-4054699
Code cleanup and technical improvements
The budget calculation system has been reorganized to make it easier for developers to customize and extend. Specific calculation methods were separated out from the main computation process and given clearer names, improving the overall code structure without changing how the system works for end users.
Original PR description
The methods 'get_accounts' and 'get_query' were extracted from the _compute_practical_amount method for inheritance purposes. Consequently, their names were changed to more descriptive ones.