Daily updates from Odoo
Friday, February 21, 2025
89 changes
37 changes
Enhancements to existing features
This update standardizes how bank statement CSV imports manage temporary database changes, making the process easier to maintain and more consistent. It also simplifies salary simulation rollback handling so trial calculations are fully discarded after running, reducing risk of unintended saved data.
Original PR description
### [IMP] account_bank_statement_import_csv: use savepoint() Use the savepoint object to import the data instead of custom SQL. The goal is to be able to find easily all savepoint usages and have them working in the same way. ### [IMP] hr_contract_salary: remove savepoint for simulation When simulating salary data, we want to rollback all that is done during the simulation. Since we commit just before trying to do the simulation, we can just rollback at the end instead of using savepoints. https://github.com/odoo/odoo/pull/198584
Resolved issues and error corrections
Odoo now returns more appropriate error statuses when requests fail, helping integrations and clients better understand what went wrong. This makes error handling clearer without changing core business workflows.
Original PR description
Historically Odoo always returned 400 as the default "4xx" http status code for when the customer screwed up. But 400 is actually reserved for when the http request is malformed, i.e. there was an…
Historically Odoo always returned 400 as the default "4xx" http status code for when the customer screwed up. But 400 is actually reserved for when the http request is malformed, i.e. there was an error while parsing the headers or the body (according strickly to Content-Type). The default go-to error for when the request is syntaxically valid but otherwise garbage is 422 - Unprocessable Entity. Access Denied uses 403 - Forbidden and not 401 - Unauthorized because 401 mandates the use of the `WWW-Authenticate` and `Authorization` headers which don't apply in Odoo. Missing Error uses 404 - Not Found and not 410 - Gone because Missing Error is not only used when trying to write on a deleted record, it also applies when trying to write on a record that never existed. Used the opportunity to visit some other places where we used 400 and to use a http error that is better indicated. See https://httpwg.org/specs/rfc9110.html#status.4xx for the latest specification of HTTP status codes. task-4284096
Miscellaneous changes
Since commit [6f06420e4a9443c52dc0cb427f8f55eb4aecabce](https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce), fields used in expressions in a view are automatically added to the view if not present originally. This allows all fields to be available in the expression editor for modifiers, which this commit is enabling. task-4481934 Forward-Port-Of: odoo/enterprise#79737 Forward-Port-Of: odoo/enterprise#79672
Original PR description
Since commit [6f06420e4a9443c52dc0cb427f8f55eb4aecabce](https://github.com/odoo/odoo/commit/6f06420e4a9443c52dc0cb427f8f55eb4aecabce), fields used in expressions in a view are automatically added to the view if not present originally. This allows all fields to be available in the expression editor for modifiers, which this commit is enabling. task-4481934 Forward-Port-Of: odoo/enterprise#79737 Forward-Port-Of: odoo/enterprise#79672
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158 Forward-Port-Of: odoo/enterprise#79669
Original PR description
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158 Forward-Port-Of: odoo/enterprise#79669
- Since this PR(https://github.com/odoo/enterprise/pull/77019) we were not able to settle open invoices in PoS anymore. - Now when the customer have an existing due and that due is not linked to any `pos.order` (like an open invoice), we can now settle it in PoS. To do this we redirect the user to the payment screen and pre-fill the amount to settle. - Add default `settle_product` & `deposit_product` for new `pos.config`. Also add these products for config for which session is in **Opening con
Original PR description
- Since this PR(https://github.com/odoo/enterprise/pull/77019) we were not able to settle open invoices in PoS anymore. - Now when the customer have an existing due and that due is not linked to any `pos.order` (like an open invoice), we can now settle it in PoS. To do this we redirect the user to the payment screen and pre-fill the amount to settle. - Add default `settle_product` & `deposit_product` for new `pos.config`. Also add these products for config for which session is in **Opening control** state. task-id: 4587306 Forward-Port-Of: odoo/enterprise#79605
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will
Original PR description
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection. Forward-Port-Of: odoo/enterprise#79797
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79917 Forward-Port-Of: odoo/enterprise#79790
Original PR description
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79917 Forward-Port-Of: odoo/enterprise#79790
See commits :-) Forward-Port-Of: odoo/enterprise#79743 Forward-Port-Of: odoo/enterprise#79264
Original PR description
See commits :-) Forward-Port-Of: odoo/enterprise#79743 Forward-Port-Of: odoo/enterprise#79264
Before this commit, when we clicked on the activity send tax report. It would result by opening the report at the current date instead of the date of the move. After this commit, the expected behaviour was to open the move of the tax closing. task-4583606 Forward-Port-Of: odoo/enterprise#79807 Forward-Port-Of: odoo/enterprise#79511
Original PR description
Before this commit, when we clicked on the activity send tax report. It would result by opening the report at the current date instead of the date of the move. After this commit, the expected behaviour was to open the move of the tax closing. task-4583606 Forward-Port-Of: odoo/enterprise#79807 Forward-Port-Of: odoo/enterprise#79511
Steps to reproduce the bug: - Create two storable products “P1” and “P2”: - Tracked by Serial Number - Create a quality control point: - Operation: Receipt - Control per: Quantity - Create a receipt: - 10 units of P1 - 10 units of P2 - Mark it as "To Do." - Open the detailed operation of P1: - Assign two SNs: - SN1 - SN2 - Save. - The “Quantity” field of the P1 move is updated to 2. - Mark the move of P1 as "Picked." - Validate the receipt. - The backorde
Original PR description
Steps to reproduce the bug:
- Create two storable products “P1” and “P2”:
- Tracked by Serial Number
- Create a quality control point:
- Operation: Receipt
- Control per: Quantity
- Create a receipt:
- 10 units of P1
- 10 units of P2
- Mark it as "To Do."
- Open the detailed operation of P1:
- Assign two SNs: - SN1 - SN2 - Save.
- The “Quantity” field of the P1 move is updated to 2.
- Mark the move of P1 as "Picked."
- Validate the receipt.
- The backorder wizard is triggered → Validate it.
Problem:
A wizard to process the quality check is triggered, but 12 quality checks (2 for P1 and 10 for P2) are loaded instead of only 2 for P1.
Expected Behavior:
Quality checks should only be triggered for picked moves
opw-4442564
Forward-Port-Of: odoo/enterprise#79810
Forward-Port-Of: odoo/enterprise#76478**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;  - Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`). ___ **Issue:** Can't access `EC Sales List` o
Original PR description
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or…
**Steps to reproduce:**
- Use the `NL Company`;
- Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`):
- Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;
- Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`).
___
**Issue:**
Can't access `EC Sales List` of the Dutch company after deleting any or both of the `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers.
___
**Expected:**
Users should be able to access `EC Sales List` even when an identifier is deleted as there is a fallback.
___
**Cause:**
The fallback doesn't refer to the good tax options.
https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/models/account_sales_report.py#L82-L84
___
**Fix:**
Adapt the fallback references' module for retrieval as done for testing in: https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/tests/test_sales_report.py#L22-L24
___
opw-4425376
Forward-Port-Of: odoo/enterprise#78314
Forward-Port-Of: odoo/enterprise#76366clipboard_macros.js : use hoot action instead of action implemented in web/core/macro.js (The goal is to definitly remove this actions from macro.js) tour_shopfloor.js : Ensure body has not visible modal (and not just modal) preparation_display_tour.js : WaitRequest after clickOrderButton. tour_shopfloor.js : additional step to ensure state of DOM. tour_test_mrp_barcode_flows.js : additional step to ensure state of DOM. No need to click on the input when use edit() action.
Original PR description
clipboard_macros.js : use hoot action instead of action implemented in
web/core/macro.js (The goal is to definitly remove this actions
from macro.js)
tour_shopfloor.js : Ensure body has not visible modal (and not just
modal)
preparation_display_tour.js : WaitRequest after clickOrderButton. tour_shopfloor.js : additional step to ensure state of DOM. tour_test_mrp_barcode_flows.js : additional step to ensure state of DOM.
No need to click on the input when use edit() action. edit() already
click in input to focus it.
export_tours.js : additional step to ensure state of DOM. helpdesk_knowledge_template_bloc_tour.js : No need to click when the
step is just a DOM check.
website_sale_change_rental_duration.js : additional step to ensure
state of DOM.
Forward-Port-Of: odoo/enterprise#79755
Forward-Port-Of: odoo/enterprise#79358Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Original PR description
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#78300 Forward-Port-Of: odo
Original PR description
Before this commit, the test was relying in "today's" date for creating the recurring invoices. Since the time period for generating them was too short, the expected deliveries were not being generated. After this commit, we give a fixed date to the start date of the subscriptions and then generate the recurring invoices with a time distance of a month, solving the issue. Issue-from: OPW-4166852 Related PR: odoo/enterprise#73397 Forward-Port-Of: odoo/enterprise#78300 Forward-Port-Of: odoo/enterprise#76336
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
Original PR description
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Original PR description
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79579 Forward-Port-Of: odoo/enterprise#75552
Original PR description
When an employee takes a leave, the private car reimbursement amount is reduced by a certain amount. However, when they take multiple leaves, the computation doesn't follow. This commit fixes the issue. task-4353922 Forward-Port-Of: odoo/enterprise#79579 Forward-Port-Of: odoo/enterprise#75552
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efa
Original PR description
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called,…
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efabfed5c1 Before: 3.51s (`_create_checks`) - 17493 queries (total queries of the script, not for the single operation)  After: 2.08s (`_create_checks`) - 16103 queries (total queries of the script, not for the single operation)  Comparison of the time taken by Confirming the MRP Order (using `time.process_time()`) | n_components | before (s) | after (s) | ratio | | --- | --- | --- | --- | | 1 | 0.074 | 0.073 | 0.988 | | 5 | 0.134 | 0.140 | 1.042 | | 10 | 0.216 | 0.187 | 0.862 | | 20 | 0.334 | 0.304 | 0.908 | | 50 | 0.736 | 0.600 | 0.816 | | 100 | 1.378 | 1.172 | 0.851 | | 200 | 2.739 | 2.374 | 0.867 | Forward-Port-Of: odoo/enterprise#77608 Forward-Port-Of: odoo/enterprise#65725
Forward-Port-Of: odoo/enterprise#79660
Original PR description
Forward-Port-Of: odoo/enterprise#79660
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Original PR description
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
This commit fixes a cohort test failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 Forward-Port-Of: odoo/enterprise#79738 Forward-Port-Of: odoo/enterprise#79555
Original PR description
This commit fixes a cohort test failing randomly by ensuring that we wait for the download to be completed before ending the test or asserting the steps. Runbot error-134572 Forward-Port-Of: odoo/enterprise#79738 Forward-Port-Of: odoo/enterprise#79555
Due to dependencies and auto installs, Accounting was auto installed for Belgian companies. `l10n_be_reports` was auto installed if `l10n_be` and `account_reports` are installed but it also depends on `account_loans` which is an accounting feature. report by CHKL Forward-Port-Of: odoo/enterprise#79746
Original PR description
Due to dependencies and auto installs, Accounting was auto installed for Belgian companies. `l10n_be_reports` was auto installed if `l10n_be` and `account_reports` are installed but it also depends on `account_loans` which is an accounting feature. report by CHKL Forward-Port-Of: odoo/enterprise#79746
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/o
Original PR description
Test that when creating a receipt or internal transfer using the barcode app, the description_picking field of the move_line is not empty. Steps to reproduce the issue: - Create a product with a description for receipts (e.g., 'receipt'). - In the barcode app, create a new receipt and add the product (leave it in draft). - In the inventory app, check the corresponding receipt. - The move_line has no description_picking, even though the product has one. community: https://github.com/odoo/odoo/pull/193996/files opw-4406582 Forward-Port-Of: odoo/enterprise#79608 Forward-Port-Of: odoo/enterprise#79349
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from a
Original PR description
An error occurs when triggering a cron job for posting all pending posts. ```ValueError: Expected singleton: social.post(14, 13)``` A singleton error occurs when the system tries to get a value of 'post_method' from multiple records at [1]. Link [1]: https://github.com/odoo/enterprise/blob/5e968dfce025102bc27f01ba9b07304477835b47/social_push_notifications/models/social_post.py#L26 To avoid the singleton error, we can use the ```mapped()``` function to retrieve a list of values from all the records and check the condition across them. Sentry-6055370689 Forward-Port-Of: odoo/enterprise#74698
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create arti
Original PR description
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create article without any errors. Also prevent unnecessary write on empty recordset. Task-4414401 Forward-Port-Of: odoo/enterprise#76349
related - https://github.com/odoo/odoo/pull/198328 Forward-Port-Of: odoo/enterprise#79690
Original PR description
related - https://github.com/odoo/odoo/pull/198328 Forward-Port-Of: odoo/enterprise#79690
Before this commit: === - Certain UrbanPiper-related products (product_packaging_charges, product_delivery_charges, product_other_charges) could be archived, leading to test case failure in l10n_in. After this commit: === - The corresponding product.template records are explicitly reactivated after calling archive_products(cls.env), ensuring they remain available for use. runbot-115160 Forward-Port-Of: odoo/enterprise#79645
Original PR description
Before this commit: === - Certain UrbanPiper-related products (product_packaging_charges, product_delivery_charges, product_other_charges) could be archived, leading to test case failure in l10n_in. After this commit: === - The corresponding product.template records are explicitly reactivated after calling archive_products(cls.env), ensuring they remain available for use. runbot-115160 Forward-Port-Of: odoo/enterprise#79645
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will
Original PR description
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags. After this commit: the line break is there and the words are not join together anymore. OPW-4079729 Forward-Port-Of: odoo/enterprise#78307 Forward-Port-Of: odoo/enterprise#73727
taskid : 4471762 Forward-Port-Of: odoo/enterprise#79756 Forward-Port-Of: odoo/enterprise#77483
Original PR description
taskid : 4471762 Forward-Port-Of: odoo/enterprise#79756 Forward-Port-Of: odoo/enterprise#77483
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/ente
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/enterprise#78421 Forward-Port-Of: odoo/enterprise#78085
before this commit: Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly. After this commit: Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters. opw-4167675 Forward-Port-Of: odoo/enterprise#79518
Original PR description
before this commit: Shipping methods are missing default vlaue of shipping functionalities, which leads to some methods getting filtered out incorrectly. After this commit: Default value of the shipping functionalities are fetched and checked to select the correct shipping method based on user filters. opw-4167675 Forward-Port-Of: odoo/enterprise#79518
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task
Original PR description
… rec widget The 'no_exchange_difference' is used to prevent exchange diff in the whole reconciliation. However, the reconciliation is recursive when dealing with CABA entries. From the bank reconciliation widget, we want to prevent the exchange diff only for the top reconciliation but not recursively. Otherwise, the CABA entry ends up with a residual amount but considered as fully reconciled. Instead, let's use 'no_exchange_difference_no_recursive'. See the test in this commit. task-id: 4531511 Forward-Port-Of: odoo/enterprise#78538 Forward-Port-Of: odoo/enterprise#78205
- we made some typo here https://github.com/odoo/enterprise/pull/77329/commits/0005513aedee0fce8db174dc25846d17f46f056b#diff-636ce727908264dec04ea3634d7cea514ba8f21344134c239c474d989abcf266R144 and we lost the ```manage versions ``` from the action. Task-4586706 Forward-Port-Of: odoo/enterprise#79571
Original PR description
- we made some typo here https://github.com/odoo/enterprise/pull/77329/commits/0005513aedee0fce8db174dc25846d17f46f056b#diff-636ce727908264dec04ea3634d7cea514ba8f21344134c239c474d989abcf266R144 and we lost the ```manage versions ``` from the action. Task-4586706 Forward-Port-Of: odoo/enterprise#79571
RATIONALE Cleanup addon-specific code about default recipients computation. Since base code is now smarter, most overrides can be removed to keep simple code and ease understanding. SPECIFICATIONS Remove overrides that are now covered by base computation. When necessary use '_mail_defaults_to_email' that prioritizes email over partner (customer) when searching for default recipients. When necessary add missing '_primary_email' definition allowing to find the main email to cont
Original PR description
RATIONALE Cleanup addon-specific code about default recipients computation. Since base code is now smarter, most overrides can be removed to keep simple code and ease understanding. SPECIFICATIONS…
RATIONALE Cleanup addon-specific code about default recipients computation. Since base code is now smarter, most overrides can be removed to keep simple code and ease understanding. SPECIFICATIONS Remove overrides that are now covered by base computation. When necessary use '_mail_defaults_to_email' that prioritizes email over partner (customer) when searching for default recipients. When necessary add missing '_primary_email' definition allowing to find the main email to contact. Provide some fixes in default recipients computation, notably linked to normalized emails usage and comparison instead of raw emails. QUERIES Simple overrides on test models are removed. This implies usage of more complete '_message_get_default_recipients' hence some additional queries. LINKS Followup of odoo/odoo#172714: improve default behavior of templates Followup of odoo/odoo#188642 : main branch for email-like recipients Task-4555506: Cleanup / Mergeup default / suggested recipients Forward-Port-Of: odoo/enterprise#79590
Back port of #78809 Forward-Port-Of: odoo/enterprise#79694
Original PR description
Back port of #78809 Forward-Port-Of: odoo/enterprise#79694
With this commit ================ - Renamed the return value of the getName method to `Inventory Count` for consistency with the Inventory Count button on the main page. - Rephrased toaster message for Inventory Adjustment Validation. - Updated the domain in the product form of Inventory Count to include `storable/inventory tracked` products. Task: [4458119](https://www.odoo.com/odoo/my-tasks/4458119) Forward-Port-Of: odoo/enterprise#79715 Forward-Port-Of: odoo/enterprise#79154
Original PR description
With this commit ================ - Renamed the return value of the getName method to `Inventory Count` for consistency with the Inventory Count button on the main page. - Rephrased toaster message for Inventory Adjustment Validation. - Updated the domain in the product form of Inventory Count to include `storable/inventory tracked` products. Task: [4458119](https://www.odoo.com/odoo/my-tasks/4458119) Forward-Port-Of: odoo/enterprise#79715 Forward-Port-Of: odoo/enterprise#79154
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
Original PR description
Refactors the button bar component and makes the xlsx button always show on accounting reports. task-4402561 Forward-Port-Of: odoo/enterprise#75884 Forward-Port-Of: odoo/enterprise#73580
52 changes
Enhancements to existing features
Invoice lists can now be searched using the total invoice amount. This makes it easier for users to quickly find specific invoices when they know the amount but not other details.
Original PR description
It would help people to be able to search on the Total amount for invoices task-4575021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale order amounts now use the currency linked to each session, so values display and behave according to the right monetary precision. This improves consistency for businesses using different currencies and simplifies related quality checks.
Original PR description
check commit message for description
The Indian e-invoicing module now rejects pincodes outside the valid government-defined range, such as 000000. This helps prevent invalid partner address data from causing issues during e-invoice submission.
Original PR description
As per the [government schema for json](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#requestPayload), the pincode should be in range of 100000 and 999999 but in odoo we only validated string of 6 digit character Before this commit- if a partner with pincode `000000` then no validation error After this commit- if a partner with pincode `000000` invalid pincode validation raises 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
Automated guided tour tests now better detect unstable page behavior by waiting briefly after finding a target and confirming it remains visible and unchanged. This helps reduce unreliable test results and improves confidence in product quality checks.
Original PR description
in this commit, we improve the method to look for indeterminisms in the tours. The method waits a certain amount of time once the trigger has been found and then checks if the element is still visible, if it has changed or if it has undergone mutations. We take advantage of this commit to also improve the method to find the trigger in the DOM (we check that body does not have the class o_is_blocked and that the frame is is-ready=true if the element is in an iframe)
The point of sale system now includes a dedicated way to apply discounts during sales flows. This helps make discount-related actions more consistent and easier to reuse in the checkout experience.
Original PR description
add a function to add discount
The Knowledge app now relies on the shared HTML editor for content migration instead of maintaining its own migration logic. This reduces duplication and helps keep Knowledge, Website Knowledge, and related features aligned with the standard editor behavior.
Original PR description
This commit moves the html_field migration system to the standard. See implementation in 0df669159aaa1a9631ab12a68758bf78954071f7. Removing the Excalidraw command means that the html migration system must be moved to `html_editor`. This commit thus removes the sytem from Knowledge and adapts the manifests to take into account the move done, and updates a test to account for the new html editor version (1.1). task-4489076
Resolved issues and error corrections
The Accounting dashboard now keeps journal card graphs aligned with the bottom of each card, even when cards have different numbers of action links. This fixes a visual inconsistency introduced during a previous redesign and makes the dashboard cleaner and easier to scan.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard - Make sure that one journal has more action links than the other ones of the same row **Issue:** There is an offset between the bottom border of the kanban card and the graph that depends on the difference between the number of action links in the current card and the higher number of action links in a card on the same row.  **Cause:** The view has been refactored in version 18.0 and some css has been lost in the process. opw-4473451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now safely handles cases where no text or content is selected in Firefox. This prevents an unexpected browser-specific error, improving editing reliability for users.
Original PR description
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the online checkout from crashing when customers switch between addresses that have different delivery availability. It helps Click & Collect shoppers continue checkout smoothly even when a delivery option is not available for one address.
Original PR description
Steps to reproduce: 1) Install Click & Collect 2) Configure a standard delivery to deliver only to Belgium and publish 3) Unpublish the others 4) Go to /shop page add a storable product 5) Proceed to /checkout add two addresses one with US country, the other with Belgium 6) Try to click on US partner then on Belgium then again on US 7) Observe traceback After this commit we skip the check in _canEnableMainButton if a radio element is not found.
This fixes an issue where invoice numbers and customer references could appear twice when viewing journal entry lines from aged receivable reports. The change makes report line descriptions cleaner and easier for accounting users to read.
Original PR description
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases. ### Steps to reproduce: - Go to Accounting > Reports > Aged Receivable - Unfold any customer shown, click on the…
The previous [fix](https://github.com/odoo/odoo/pull/195449) did not cover all cases.
### Steps to reproduce:
- Go to Accounting > Reports > Aged Receivable
- Unfold any customer shown, click on the three dots next to an invoice, and select "View Journal Entry"
- On the Journal Entry, add the something to Customer Reference
- Go back to the report, you should see the invoice name and Customer reference are shown twice
### Cause:
The bug appeared in this commit (https://github.com/odoo/odoo/commit/eb872c09897eb9edd5b6e5b9e8171fa6764be3dc) when computing the line display_name, if there is a move name, a reference and `line_name`.
The variable `line_name` already include the reference: `name = f'{line.move_id.ref} - {line.move_id.payment_reference}'` (https://github.com/odoo/odoo/commit/a6cbb7c2d3538d57dc8498f0dacf4566ea1492e7)
So `line_name` is different from `move_name` and the result is: `line.move_id.name (line.move_id.ref) line.move_id.ref - line.move_id.payment_reference`
### Solution:
The previous fix prevents `line_name` from having the same string twice. But it does not fix the issue when the invoice name and Customer reference are different.
This commit checks if `move_name` and `move_ref` are included in `line_name` before adding it to the display name.
This is not optimal as it makes this code dependent on the format of `line_name`.
opw-4492298This change adds safeguards to ensure company-specific linked records still exist before they are used. It helps prevent errors when records are removed at the same time another process is trying to reference them, improving reliability for users.
Original PR description
Added existence checks for company-dependent many2one fields to ensure assigned ids are valid and to handle cases where records are deleted concurrently. This prevents potential MissingError issues in the future. 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
Visitors who are not logged in are now politely asked to sign in when they try to react to comments, instead of seeing an access error. This improves the experience on public pages such as course reviews while keeping comment reactions limited to authenticated users.
Original PR description
Public users should not be able to react to comments. This commit politely ask them to log in. Reproduce --- - website_slides - as public - open course review - attempt to react - access error opw-4545596
The guided tour pointer now correctly detects whether a target is off-screen horizontally or vertically. This prevents misleading pointer placement during product walkthroughs, making tours clearer for users.
Original PR description
Before this commit, if an element was out of the screen on the X axis, the pointer was showing as if it was out of the screen in top. Now, it makes the difference between X and Y axis. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix avoids upgrade failures when a related tax report component is not available yet during module loading. It helps ensure smoother upgrades for customers using the Spanish Modelo 130 reporting modules.
Original PR description
During module load, a custom handler coming from a dependant module could be unavailable. Skip the check in such cases. Steps to reproduce: 1. In 17.4 install `l10n_es_reports_modelo130` 2. Upgrade to 18.0 There is an error because the model `l10n_es_modelo130.mod130.tax.report.handler` is not loaded yet. The same error is also observed if we try to upgrade `l10n_es_modelo130` in 18 after installing `l10n_es_reports_modelo130`.
Spreadsheet chart settings now show a loading spinner while chart data is still being prepared. This prevents users from seeing an incorrect error message and makes chart editing feel clearer and more reliable.
Original PR description
When we change the chart type/change the chart doamin from the side panel, there would be an error message `the model (odoo.model) of this chart is not valid`. Which was wrong, the model was valid but the data source was simply not loaded yet. This commit instead shows a loading spinner when the data source is loading. Task: [4564072](https://www.odoo.com/web#id=4564072&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Brazilian fiscal product fields now appear in a dedicated section on the Accounting tab instead of being shown under Ecommerce Shop. This makes product setup clearer for Brazilian companies and avoids confusion when both eCommerce and Brazilian tax localization are installed.
Original PR description
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting,…
**Issue:** BR fiscal product fields are incorrectly displayed under the "Ecommerce Shop" group instead of a dedicated section in the Accounting tab. **Steps to Reproduce:** 1. Install Accounting, Sales, eCommerce, and l10n_br_avatax modules. 2. Switch company settings from YourCompany to BR Company. 3. Navigate to Products > Sales Tab. 4. Fiscal information fields appear under the "Ecommerce Shop" group. Expected Behavior: BR fiscal product fields should be displayed inside a specific section inside the accounting group. Actual Behavior: BR fiscal product fields are incorrectly placed in the Ecommerce Shop group. **Root Cause** The issue occurs because the code mistakenly modifies the Extra Info group, adds eCommerce-related fields inside it, and then renames it to Ecommerce Shop. This causes the Extra Info group to disappear, leading to fiscal information being displayed incorrectly. **Fix** To avoid modifying a module unrelated to Brazilian taxes, which might have a broader impact, the existing behaviour is left unchanged. Instead, a new section has been added within the accounting tab to display the necessary information. This ensures that only the l10n_br_avatax module is modified. Opw-4533760
After splitting a PDF in Documents, the newly created documents are now automatically selected as expected. This makes the workflow smoother and helps users continue working with the new files without manually finding and selecting them.
Original PR description
Before this commit, after using the split tool new documents are created and should be automatically selected but aren't. This commit fix this issue. Task-4555273
A disabled Knowledge app test was updated to match recent changes in the article editor. This helps improve future automated test reliability without changing the user experience.
Original PR description
`test_knowledge_commands_tour` is currently disabled. Currently it is failing because the main paragraph element in the Composer was changed from `<p>` to `<div class="o-paragraph">`. This commit updates the tour to be compatible with the changes in the Composer, in hope to re-enable the test some day. runbot-task-114943 runbot-task-134158
The HTML editor now automatically scrolls to the cursor when typing moves it outside the visible area. This prevents users from losing sight of new content while adding multiple paragraphs, making editing smoother and less confusing.
Original PR description
**Problem**: When the selection moves out of the viewport while typing, the user cannot see what they are typing. **Solution**: Automatically scroll to the selection if it moves out of the viewport. **Steps to Reproduce**: 1. Open the editor. 2. Keep adding paragraphs by pressing Enter repeatedly. 3. When the selection goes out of the viewport, type some text. - The typed content is not visible. opw-4356668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, lead
Original PR description
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the…
The base URL was being retrieved incorrectly in `_compute_short_url_host()` without considering the current company. This caused the short URL to always use the domain of the company logged into the database, rather than the domain of the selected company. This happens because the base URL was retrieved using `get_current_website()` from the `website` module, which does not consider the company context. As a result, the short URL adapts based on the domain of the last logged-in company, leading to inconsistent URLs. Steps to reproduce: 1. Context: The database has two companies, Company A and Company B, each with their own custom domains, Domain A and Domain B. 2. Log in to the database using Domain A. - Post a link via social marketing for Company A. The short URL will use Domain A. 3. Switch to the Company B. - Post the same link via social marketing for Company B. The short URL will now incorrectly use Domain A instead of B. While the short URL still redirects to the correct content, the domain in the short URL is inconsistent and depends on the last logged-in domain. OPW-4235176 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194331
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state t
Original PR description
Steps to reproduce: * Open the form view of any UoM category. * Add a new line in the units list. * Without saving, Uncheck "Active" checkbox. * Before saving, change the type of this unit to reference. * Save the form. Expected behavior: An error should be thrown as it's not allowed to have more than one reference unit for some category. Current behavior: The record is normally saved without any errors. This issue caused an inconsistency when upgarding a database in such state to saas18.1, where each unit points to its reference as a parent. Having multiple references in the same category caused a having a cycle in this link. See: https://github.com/odoo/upgrade/blob/master/migrations/uom/saas~18.1.1.0/pre-migrate.py#L16-L25 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197634
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
Original PR description
Avoids inconsistencies, simplifies control flow sometimes. Not all manual savepoints are converted: - The implementation details of `Savepoint` can't exactly be converted. - The test case savepoint is difficult to convert as the savepoint name / id is "leaked" for historical reasons, but also `test_mail_bounce_during_send` does exceedingly strange stuff and needs to re-create the test savepoint because it commits multiple times... Forward-Port-Of: odoo/odoo#198537
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
Original PR description
The `rollback` decorator does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. Forward-Port-Of: odoo/odoo#198500
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Pr
Original PR description
Before this commit, when the user creates a project in the form and select a stage to directly put it in another stage then the first one given as default value. The stage is changed to set again the project in the default stage instead of keeping the choice made by the user. This commit makes sure the stage chosen by the user is still kept once the project is created. Steps to reproduce: ------------------ 1. Install project 2. Go to Project > Configuration > Settings 3. Enable the Project Stage feature 4. Go to Project > Configuration > Projects 5. Click on new button to create a new project 6. Set the project name and click on the second project stage Current Behavior: ---------------- The project goes back to the default stage instead of staying in the stage selected by the user. Expected Behavior: ----------------- The project should be in the stage selected. Forward-Port-Of: odoo/odoo#198452
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close t
Original PR description
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing…
When creating nested BoMs that share some common component, the cost of the product was being calculated incorrectly Steps to reproduce: ------------------- * Set `All` category to use the costing method `AVCO` in the settings. * Create a product Comp1 and set its cost to 100. * Create Product P1 with a BoM that consumes 1 Comp1. * Create Product P2 with a BoM that consumes 1 Comp1. * Create Product P3 with a BoM that consumes 1 P1. * Create a POS order with 1 P2, and 1 P3. * Close the session and check the cost of the products in the order > Observation: The cost for P3 is incorrect, it should be 100 but it is 200. Why the fix: ------------ When selecting the stock moves line to consider for the cost of the PoS order, we need to select the stock moves that are related to the BoM lines of the original product. In the previous code we were only relying on the product id, and this was causing the issue because some products can have the same product id but used in different BoM lines. opw-4201935 Forward-Port-Of: odoo/odoo#198036 Forward-Port-Of: odoo/odoo#193717
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an e
Original PR description
Current behavior before PR: - If a sequence_override_regex is set to a custom year regex, the default year_range regex is used instead if it matches the invoice name too. - Creating a new invoice fails if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. Desired behavior after PR is merged: - If a sequence_override_regex is set, the default regexes are never used. - Creating a new invoice succeeds even if the custom sequence regex doesn't accept an empty or draft (i.e. '/') invoice name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198492 Forward-Port-Of: odoo/odoo#196106
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
Original PR description
By default, if no date are specified, an invoice is dated at today. The test enforces a name in 2024, which is why it worked before. Now, as we're not in 2024, the test always fails. The generated pdf does not have the same name, as it follows the invoice name. Let's force the date of the invoice, to force the name of the pdf. runbot-111405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198314
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: - P1 -> 2 units - P2 -> 2 units - Validate the receipt and create a backorder. Problem: A picking is validated with only 2 units of P2, and a backorder is created with 5 units of P1 and 3 units of P2, instead of correctly validating the picking with: - P1 -> 2 units -
Original PR description
Steps to reproduce the issue: - Create a storable product P1. - Create a subcontracted product P2. - Create a receipt with 5 units of P1 and P2. - Mark it as To Do. - Set the quantities as follows: -…
Steps to reproduce the issue:
- Create a storable product P1.
- Create a subcontracted product P2.
- Create a receipt with 5 units of P1 and P2.
- Mark it as To Do.
- Set the quantities as follows:
- P1 -> 2 units
- P2 -> 2 units
- Validate the receipt and create a backorder.
Problem:
A picking is validated with only 2 units of P2, and a backorder is
created with 5 units of P1 and 3 units of P2, instead of correctly
validating the picking with:
- P1 -> 2 units
- P2 -> 2 units
And creating a backorder with:
- 3 units of P1
- 3 units of P2
This occurs because, when updating the move for P2 from 5 to 2, a move
line is created and marked as picked. As a result, when computing the
picked value for the move, it is also marked as picked:
https://github.com/odoo/odoo/blob/7dda6bb92715ea25b2818a62fec5e646f3678b81/addons/stock/models/stock_move.py#L206-L207
Thus, when validating the picking, since only the move for P2 is marked
as picked, it is the only one that gets validated.
opw-4357997
Forward-Port-Of: odoo/odoo#189481Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Original PR description
Revert of commit ca1fa38815070325e3b998efcc0ec0d663b2f3b8 The fix introduced the impossibility of manually editing the duration days of attendances due to a depends cycle. The duration days of attendance should be manually editable. Forward-Port-Of: odoo/odoo#198379
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197589 Forward-Port-Of: odoo/odoo#197502
Original PR description
Steps to reproduce: 1. Write anything in a searchbar 2. Navigate on togglable item 3. Press arrowleft 4. Hold arrowright -> It will spam name_search queries We fix this by checking that the "arrowright" event isn't held (repeat=false). Task: 4476832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197589 Forward-Port-Of: odoo/odoo#197502
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. I
Original PR description
Follow-up to #190162 Steps to reproduce: - Create a new Manufacturing Order - Set a product that is in stock as component with a quantity of 1 - Confirm the Manufacturing Order Issue: The component will be displayed in yellow (i.e. overconsumption), as the condition checks always on `should_consume_qty`, which is the quantity that should be used for that amount of `qty_producing`. But that quantity will *always* be 0 for confirmed MOs, as the `qty_producing` will be 0 at the time. Instead, while the MO isn't started yet, we can simply compare to the demand to see if there's enough reservation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198593
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it
Original PR description
## How to Reproduce: - Create products P1 & P2, storable - Create receipt picking for 1 unit of P1 -> Confirm - Open receipt in 2 browser tabs. - In Tab 1, add a new operation line for 1 unit of P2. !Do Not Save! - In Tab 2, validate the receipt. - In Tab 1, save. => Picking went from Ready -> Done -> Ready. Move P1 state = 'done' while move P2 state ='assigned' ## Solution: When a move is added to a Done picking, we change the state of the move to done, and the move is treated like it was added to a Done unlocked picking. OPW-3919976 Forward-Port-Of: odoo/odoo#198601 Forward-Port-Of: odoo/odoo#196161
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.
Original PR description
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages. * `python3-cryptography` is installed by `python3-openssl` * `python3-idna` and `python3-urllib3` are installed by `python3-requests` * `python3-markupsafe` is installed by `python3-jinja2` Forward-Port-Of: odoo/odoo#198102 Forward-Port-Of: odoo/odoo#197302
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
Original PR description
Before this commit we had a schemeID equals to TN every time. But it should be equals to TN only if the partner is from 'JO' otherwise 'PN' task: 4547131 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196619
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish s
Original PR description
**Steps to Reproduce:** 1. Create a new page using the **"New"** button and save it. 2. Publish the page using the **"Publish/Unpublish"** button. 3. Enter **Edit** mode (without reloading the page), update the page content, and save. 4. The SEO notification does not appear. **Reason for Change:** This PR fixes an issue where SEO notifications were not displayed after creating, publishing, editing, and saving a page. The fix ensures SEO data includes the website's publish status, which was previously missing in [1](https://github.com/odoo/odoo/commit/45ea6e4a4a5c8e314b110a45198fbe3d57bb996e). This update guarantees that the notification appears only when necessary. task- 4046471 Forward-Port-Of: odoo/odoo#173793
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attach
Original PR description
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attachments/assets/df32dbc8-d042-4802-a9b4-2f3d93e97963" /> Forward-Port-Of: odoo/odoo#198320
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross com
Original PR description
Before this commit: Failing to print for whatever reason would yield some unhelpful error message like: `ghostscript._gsprint.GhostscriptError: Fatal` the error details is hidden within the stderr. Note: in general case, any stderr is logged in the IoT logs due to ExceptionLogger, however it's not the case here (probably due to some ghostscript wrapping). After this commit: A more explicit error message with details regarding the error and some relevant debug information to cross compare opw-4481596 Forward-Port-Of: odoo/odoo#198480
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79515 Forward-Port-Of: odoo/enterprise#76341
Original PR description
Couldn't: - read measurements from scales, - validate, skip, pass or fail quality checks with a footswitch. Tasks: 4432802 Forward-Port-Of: odoo/enterprise#79515 Forward-Port-Of: odoo/enterprise#76341
The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 Forward-Port-Of: odoo/enterprise#79111
Original PR description
The Book keeper was not able to see the General info of bank accounts and so on - The problem was that there was an xpath that overwrite the groups - I was not able to remove the view file as it will affect our database and that may affect the system. - We may need to remove that file in the master Task-4567218 Forward-Port-Of: odoo/enterprise#79111
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
Original PR description
They're not in loop (that I can see) so are unlikely to trigger odoo/odoo#71395, but the use of manual savepoint seems unwarranted. Using non-flushing savepoint to avoid risks of behaviour change. Forward-Port-Of: odoo/enterprise#79815
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invo
Original PR description
In scenarios where invoices are in USD and payments in MXN, the SAT requires the 'equivalenciaDR' (exchange rate) to reflect how many units of the invoice currency (USD) equal one unit of the payment currency (MXN). Previously, using the official exchange rate and rounding could produce one- or two-cent differences, causing some PACs (e.g., Quadrum) to reject the payment CFDI (CRP20268 error). This replaces the use of the official rate (and its rounding) with the absolute quotient of the invoice and payment amounts (`invoice_amount / payment_amount`). This approach removes rounding discrepancies and ensures consistent values in the XML, preventing these rejections. Forward-Port-Of: odoo/enterprise#79038
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will
Original PR description
The `rollback` decorator of `account_acountant` does not properly `release` its savepoint, leading to the subtransaction remaining present until the end of the current transaction (or a rollback to the start of the test). This is unlikely to trigger odoo/odoo#71395 (though not impossible as one of the savepoints is in a test) but it's still bad form and unnecessary: an explicit `close` will *rollback and release* the savepoint, so `savepoin()` can just be wrapped into a `closing()` which will do that for us. For `web_gantt` the savepoint is closed but not on all paths (if `ValueError` is raised the savepoint is never rolled back let alone closed), the manual use is also rather unnecessary as we can just rollback around the relevant method call, none of the later mess interacts with the cursor / connection. Forward-Port-Of: odoo/enterprise#79797
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
Original PR description
Currently, if two taxes in Odoo database matche Avatax name, it will apply both of them on the invoice line therefore duplicating this tax amount on this line. Now we only take the first tax found in database. opw-4493544 Forward-Port-Of: odoo/enterprise#79695
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
Original PR description
The Bookkeeper should be allowed to create modify and remove the asset as requested - I have edited the security file in asset model making it group_account_user task-4567264 Forward-Port-Of: odoo/enterprise#79106
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
Original PR description
We swap them to that we first have the deferred revenue report first, then the deferred expense report so that we have the same logical order as the Customer then Vendors menu items in the navbar. task-none Forward-Port-Of: odoo/enterprise#79790
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Original PR description
Previously, in RTL mode, sidebar resizing calculations were incorrect, causing the sidebar to not follow the mouse properly resulted in incorrect resizing. This fix ensures accurate resizing behavior. Task-4571290 Forward-Port-Of: odoo/enterprise#79568 Forward-Port-Of: odoo/enterprise#79379
Forward-Port-Of: odoo/enterprise#79660
Original PR description
Forward-Port-Of: odoo/enterprise#79660
See commits :-) Forward-Port-Of: odoo/enterprise#79621 Forward-Port-Of: odoo/enterprise#79264
Original PR description
See commits :-) Forward-Port-Of: odoo/enterprise#79621 Forward-Port-Of: odoo/enterprise#79264
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Original PR description
This commit fixes an issue with the X api calls where the oauth_signature was no longer correct in recent Python versions. `url_quote` used to consider the character `,` as unsafe and quoted it when creating the signature. From Python3.11 this method consider it as reserved but not as unsafe thus not quoting it. This change restores the old behavior to quote so as to respect the oauth_signature format given by X's doc. task-4583612 Forward-Port-Of: odoo/enterprise#79834
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create arti
Original PR description
Steps to reproduce ================== 1. Allow edit access to portal user on published article. 2. Try to create a child article from the portal user. When the portal user tries to create sub article it sets 'website_published' to true and inverse the field 'is_published' which force to write on the same article. As 'is_published' is not included in the portal writable field it throws an access error. After this commit ================== This commit allows portal user to create article without any errors. Also prevent unnecessary write on empty recordset. Task-4414401 Forward-Port-Of: odoo/enterprise#76349
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will
Original PR description
Before this commit: When a user in Odoo uses the dialog box to send a message to a WhatsApp number and inserts a line break with "Shift+Enter," it creates a <br> tag. In the WhatsApp module, these tags are stripped, causing the word before and the word after the <br> tag to be joined together without a space or a line break to separate them. How to reproduce: Send a message via the dialog box to a WhatsApp number and insert a line break using Shift+Enter. On the phone, the line break will not be present anymore because the tag <br> is removed with the other tags. After this commit: the line break is there and the words are not join together anymore. OPW-4079729 Forward-Port-Of: odoo/enterprise#78307 Forward-Port-Of: odoo/enterprise#73727
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efa
Original PR description
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called,…
During the creation of quality checks a potentially useless `search` was performed. With this commit, we will perform (indirectly) the search only if needed When method `_create_checks` is called, `quality.check` records are created one at the time. This can become slow wh en a lot of checks are created at once (ex: Bill of Material defined with steps "manual consumption" and used in a manufacturing order). Script used for tests: https://gist.github.com/emi-odoo/d4c6271363dfc3f2e4b7c5efabfed5c1 Before: 3.51s (`_create_checks`) - 17493 queries (total queries of the script, not for the single operation)  After: 2.08s (`_create_checks`) - 16103 queries (total queries of the script, not for the single operation)  Comparison of the time taken by Confirming the MRP Order (using `time.process_time()`) | n_components | before (s) | after (s) | ratio | | --- | --- | --- | --- | | 1 | 0.074 | 0.073 | 0.988 | | 5 | 0.134 | 0.140 | 1.042 | | 10 | 0.216 | 0.187 | 0.862 | | 20 | 0.334 | 0.304 | 0.908 | | 50 | 0.736 | 0.600 | 0.816 | | 100 | 1.378 | 1.172 | 0.851 | | 200 | 2.739 | 2.374 | 0.867 | Forward-Port-Of: odoo/enterprise#66224 Forward-Port-Of: odoo/enterprise#65725