Daily updates from Odoo
Navigate
Branch
Thursday, January 1, 2026
16 changes
2 changes
Resolved issues and error corrections
This update improves the clarity of our gratuity reports by now including information on how gratuity is calculated. Previously, this crucial detail was missing, making it difficult to understand the report's figures. This change ensures greater transparency and accuracy for financial reporting.
Original PR description
Before: - We were not printing any information about how gratuity is being calculated. After: - We are going to print information about how gratuity is being calculated. task-5454700
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents orders from being accidentally cancelled due to missed payment marking, improving the POS process. It also ensures UrbanPiper orders are tracked within Odoo's internal systems.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513 Forward-Port-Of: odoo/enterprise#103102 Forward-Port-Of: odoo/enterprise#102346
4 changes
Resolved issues and error corrections
This update fixes an issue where combo line prices were incorrectly set to 'automatic' after order creation, leading to pricing inconsistencies. The change ensures combo line price types remain as originally set, allowing for accurate price updates and preventing conflicts with order processing. This improves the reliability of combo line pricing in point-of-sale transactions.
Original PR description
After commit https://github.com/odoo/odoo/commit/69057e41fb4cd800d23401ead8ae11bf7cba7c64, the price type of combo lines was changed to 'automatic' when creating the combo line. This caused the set pricelist logic to update the price of combo lines with automatic price type, which conflicts with the intended behavior. This commit ensures that the price type of combo lines is preserved as original in cases where we want to update the price, and only set to automatic in cases like loading a sale order or refunding an order. opw-5240429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241481 Forward-Port-Of: odoo/odoo#234575
A minor typo in the l10n_ec_edi_pos module prevented the correct partner (Deco Addict) from being selected when processing refunds. This fix corrects the typo, ensuring refunds are handled accurately for Ecuadorian POS transactions. This resolves a potential issue with reporting and reconciliation.
Original PR description
Step to reproduce: - install l10n_ec_edi_pos - start pos and settle order with specific partner(ex. Deco Addict) - process the refund for this order Observation: - on product screen, "Consumidor Final" is selected instead of Deco addict. Cause and Fix: - Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id` opw-5412346 Forward-Port-Of: odoo/enterprise#102998 Forward-Port-Of: odoo/enterprise#102202
This update fixes a technical issue where joining a meeting from multiple browser tabs could cause a crash. The change ensures stability when users participate in calls across different tabs, improving the overall meeting experience. This resolves a bug related to how the call's RTC session is handled.
Original PR description
**Steps to reproduce:** - Start a meeting with user A - Share the invitation link with user B - Login with user B and join the call - Open another browser tab/window with the same user B - Join the same call in that tab using the invitation link - The call ends for that user as the RTC session is terminated - **_TAB1_**: join the call again - **_TAB2_**: error **Current behavior before PR:** When the same user joined the same call from another tab or during RTC renegotiation, selfSession could temporarily be undefined. **Desired behavior after PR is merged:** This PR ensures that no crash happens when dealing with the RTC Session in a `multi-tab` scenario. task-[5263097](https://www.odoo.com/odoo/project/1519/tasks/5263097) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241578 Forward-Port-Of: odoo/odoo#240881
This update resolves an error that prevented users from opening the employee form within the Point of Sale (POS) frontend. The fix disables the employee form link on the frontend only, allowing it to function correctly in the backend where all necessary data is available. This ensures a smooth user experience for POS operations.
Original PR description
Opening employee form in the frontend was throwing an error, since not all thre required assets were available on the PoS frontend. So in this commit 57aba149b6e6927f9055124e58bed03f842329d5, we disabled openening the employee form by making the employee_id field unclikcable, both in forntend and backend!! It was enough however to only macking it unclikcable on the frontend, since it was working fine on the backend where all the required assets were loaded anyway. This commit restores the functionality on the backend, but overriding the `Many2OneField` used by the `employee_id`, and making it unclickable only on the frontned. opw-5252486 Forward-Port-Of: odoo/odoo#241100
3 changes
Resolved issues and error corrections
A minor typo in the l10n_ec_edi_pos module caused the system to incorrectly identify the customer during refund processing for specific partners (like 'Deco Addict'). This fix corrects the typo, ensuring accurate customer identification and proper refund functionality. This resolves a potential issue with order processing.
Original PR description
Step to reproduce: - install l10n_ec_edi_pos - start pos and settle order with specific partner(ex. Deco Addict) - process the refund for this order Observation: - on product screen, "Consumidor Final" is selected instead of Deco addict. Cause and Fix: - Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id` opw-5412346 Forward-Port-Of: odoo/enterprise#102998 Forward-Port-Of: odoo/enterprise#102202
This update resolves an issue where UrbanPiper orders incorrectly displayed a payment difference after completion. The fix ensures that the final payment amount is accurately reflected as $0.00, streamlining the accounting process for these orders. This improves data accuracy and reduces potential discrepancies.
Original PR description
In this commit, The amount difference should be 0.0 after the Urbanpiper order has been paid. task-5441252 Forward-Port-Of: odoo/enterprise#102894 Forward-Port-Of: odoo/enterprise#102872
This update resolves an error that prevented users from opening employee forms within the Point of Sale (POS) frontend. The fix disables the employee form link on the frontend only, allowing it to function correctly in the backend where all necessary assets are available. This ensures a smoother user experience for POS operations.
Original PR description
Opening employee form in the frontend was throwing an error, since not all thre required assets were available on the PoS frontend. So in this commit 57aba149b6e6927f9055124e58bed03f842329d5, we disabled openening the employee form by making the employee_id field unclikcable, both in forntend and backend!! It was enough however to only macking it unclikcable on the frontend, since it was working fine on the backend where all the required assets were loaded anyway. This commit restores the functionality on the backend, but overriding the `Many2OneField` used by the `employee_id`, and making it unclickable only on the frontned. opw-5252486 Forward-Port-Of: odoo/odoo#241100
2 changes
Resolved issues and error corrections
This update resolves an issue where receipt attachments sent via email were broken, preventing users from viewing them in the backend. The fix ensures receipt images are correctly returned, allowing for accurate attachments in both email and order logs. This improves the user experience and ensures receipt information is reliably accessible.
Original PR description
Steps to reproduce ------------ - Open register and create an order. - Send the receipt by email. - Check the backend order log - Receipt attachment is broken. Issue ------------- Sending a receipt created a broken attachment because the generated ticket image was not correctly returned. Fix --------- Return receipt image properly so the email and backend order show a correct attachment. -------- Task-5269024 Forward-Port-Of: odoo/odoo#236026
This update automatically marks UrbanPiper orders as paid in Odoo when they are marked as 'dispatched'. This prevents order cancellations due to missed payment marking during POS closing, improving efficiency and reducing potential errors. It also ensures UrbanPiper orders are tracked within Odoo's internal systems.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513 Forward-Port-Of: odoo/enterprise#103102 Forward-Port-Of: odoo/enterprise#102346
3 changes
Resolved issues and error corrections
This update automatically marks UrbanPiper orders as paid when they are marked as 'dispatched'. This prevents order cancellations due to missed payment marking during POS closing, improving efficiency and reducing potential errors. The update also ensures UrbanPiper orders are tracked within Odoo's internal systems.
Original PR description
*= urban_piper, black_box_be In this commit: =============== - When UrbanPiper updates an order to `dispatched`, we now automatically mark the order as paid in Odoo. - This prevents the order from being cancelled during the POS session closing if the cashier forgot to mark it as ready. - Also, we are adding this urban piper order to the blackbox, if it was not recorded in it. Task: 5261892 X-original-commit: 808cf7b3f8c185053dac5cbf75307efa67fd6e90 Forward-Port Of:odoo/enterprise#99513 Forward-Port-Of: odoo/enterprise#102346
A recent issue with the Point of Sale system caused product prices to be incorrectly halved when processing sales in different currencies. This fix corrects the currency conversion logic, ensuring prices are accurately doubled as intended. This resolves a discrepancy in pricing calculations during transactions.
Original PR description
Step to reproduce: - create sale and invoice journal with different currency (say eur with rate=2) - setup new pos with this journal - open pos - select a product Observation: - notice, the product prices halved instead of double. Cause: - during this commit [1], we mistakenly reverse the conversion logic, hence price become halved rather than double. [1]https://github.com/odoo/odoo/commit/1ee02f8a47d42d3ba3fd11ffcf8d9768ea17678e Fix: - Fixed the conversion arguments opw-5434403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request represents a preliminary test to ensure the PR process is functioning correctly within Odoo 19.0. It serves as a placeholder to demonstrate the required JSON output format for summarizing pull requests. The changes are purely for testing the PR summarization tool and do not represent a functional update to the Odoo codebase.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
2 changes
Resolved issues and error corrections
This update resolves an issue where removing an icon from a paragraph would leave it unusable. The fix ensures that paragraphs remain editable and accessible after icon removal, improving the user experience. It also addresses a bug where pressing 'Enter' before an icon wouldn't insert a new paragraph.
Original PR description
**Issue 1:** Steps to reproduce: - Insert a icon in an empty paragraph. - Remove the inserted icon. - The paragraph becomes unreachable. Cause: - When a paragraph contains only an icon, removing that…
**Issue 1:** Steps to reproduce: - Insert a icon in an empty paragraph. - Remove the inserted icon. - The paragraph becomes unreachable. Cause: - When a paragraph contains only an icon, removing that icon during the delete process does not trigger `fillEmpty`. As a result, the paragraph ends up with no content, leaving it empty and unreachable. Solution: - During the delete process, after the icon is removed, call the `fillEmpty` method. This ensures that if the block becomes empty, a `<br>` is inserted inside the paragraph, keeping it accessible. **Issue 2:** Steps to reproduce - Insert an icon in an empty paragraph. - Place the cursor before the icon. - Press Enter. - Nothing happens. Cause - When the cursor is placed before a `contenteditable=false` element, `getDeepRange` sets the selection deep inside the non-editable element as a result, when Enter is pressed, the action is ignored because the selection is not in an editable context. Solution - Instead of setting the selection inside `getDeepRange`, set the selection after calling `getDeepRange` only if the returned range is not within a `contenteditable=false` element. task-3540454 Forward-Port-Of: odoo/odoo#241052 Forward-Port-Of: odoo/odoo#237891
This update resolves a previous issue where MRP planning tests were failing on weekends due to the absence of work intervals. The fix now includes a fallback for Friday, ensuring consistent test results. Additionally, the test performance has been significantly improved by reducing the planning timeframe, resulting in faster test execution.
Original PR description
overlook of https://github.com/odoo/odoo/pull/239717 ### Before this commit: Runbot was red on weekends, as there are no work intervals on weekends. ### After this commit: Use Friday as a fallback on…
overlook of https://github.com/odoo/odoo/pull/239717
### Before this commit:
Runbot was red on weekends, as there are no work intervals on weekends.
### After this commit:
Use Friday as a fallback on weekends. In addition, improve the test performance by mocking the total number of weeks of planning to 2 instead of 50 (before: 6s, after: 1s).
runbot-237575
---
Note: ran the test for the next 5 years, and it works :+1:
```diff
diff --git a/addons/mrp/tests/test_bom.py b/addons/mrp/tests/test_bom.py
index 7acf19e89add..bfadc8e487c1 100644
--- a/addons/mrp/tests/test_bom.py
+++ b/addons/mrp/tests/test_bom.py
@@ -13,6 +13,7 @@ from odoo.tests.common import HttpCase, tagged, freeze_time
from odoo.tools import float_compare, float_round, float_repr
+@tagged("-at_install", "post_install")
@freeze_time(fields.Date.today())
class TestBoM(TestMrpCommon):
@@ -963,6 +964,16 @@ class TestBoM(TestMrpCommon):
self.assertEqual(report_values['lines']['operations_time'], 15.0)
self.assertEqual(report_values['lines']['producible_qty'], 2)
+ def test_bom_report_planning_with_producible_qty_loop(self):
+ from datetime import date # noqa: PLC0415
+ start, stop = date.today(), date.fromisoformat("2031-01-01")
+ with freeze_time(start) as frozen_date:
+ for i in range((stop - start).days):
+ print("date:", str(date.today()))
+ with self.subTest(str(date.today())):
+ self.test_bom_report_planning_with_producible_qty()
+ frozen_date.tick(timedelta(days=1))
+
def test_21_bom_report_variant(self):
""" Test a sub BoM process with multiple variants.
BOM 1:
```