Daily updates from Odoo
Navigate
Branch
Sunday, March 22, 2026
14 changes
4 changes
Resolved issues and error corrections
This update fixes a user experience issue where selecting 'Select All' for employee declarations didn't generate PDFs for all records. Now, all records are processed when 'Select All' and 'Generate PDFs' are used. Additionally, users can easily regenerate PDFs for existing documents.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232
This update resolves issues related to payment processing within the Point of Sale (POS) system. Specifically, it corrects a bug where multiple payment methods on a single order caused errors and ensures that a customer is required when using certain payment methods (like receivable or cash exceeding 10,000 JOD).
Original PR description
This commit fixes the following issues 1) Having more than one payment method on a pos.order led to an error 2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD task-6005832 Forward-Port-Of: odoo/odoo#255222 Forward-Port-Of: odoo/odoo#252631
This update resolves an issue where multiple stock valuation closings with different accounting dates caused an 'Invalid Operation' error. The fix ensures the system correctly uses the accounting date when validating closing entries, preventing this conflict and ensuring accurate inventory valuation.
Original PR description
**Issue**: Making two stock valuation closings with different accounting dates in the past, on the same day, leads to an "Invalid Operation" error. **Steps to reproduce**: - In settings, set…
**Issue**: Making two stock valuation closings with different accounting dates in the past, on the same day, leads to an "Invalid Operation" error. **Steps to reproduce**: - In settings, set inventory valuation at invoicing - Create 2 bills of a storable product:: - `Accounting date` = `bill date` = today - 2 days - `Accounting date` = `bill date` = today - 4 days - Go to Accounting > Review > Inventory > Inventory Valuation - Set the day to today - 3 days, generate and post the entry - Go back the Inventory Valuation - Set the day to today - 1 day, generate the entry -> Invalid Operation error: the system thinks it exists a closing entry after the selected date. **Cause**: The regression was introduced by commit https://github.com/odoo-dev/odoo/commit/594654deb84ba45e9a6a765b89de79e4ce4e4b50 Indeed, `_get_last_closing_date` was modified to prioritize the creation date of the closing instead of its accounting date: https://github.com/odoo/odoo/blob/594654deb84ba45e9a6a765b89de79e4ce4e4b50/addons/stock_account/models/res_company.py#L336 As a consequence, the second closing with at_date = today - 1 day was compared against last_closing_date = today (creation date): https://github.com/odoo/odoo/blob/b3559145febc16271c78ca516af9d7e99bf3452f/addons/stock_account/models/res_company.py#L53-L55 **Solution** To avoid to revert this commit https://github.com/odoo-dev/odoo/commit/594654deb84ba45e9a6a765b89de79e4ce4e4b50 fix, both creation and accounting date are used. opw-5559264 Forward-Port-Of: odoo/odoo#249734
This update resolves a bug where discounts weren't consistently applying correctly when switching between fiscal positions (which handle taxes) in the Point of Sale system. The fix ensures that discount calculations now accurately reflect the current fiscal position, preventing incorrect line amounts. This improves the reliability of pricing and order totals.
Original PR description
Steps to reproduce ------------------ 1. Make two fiscal positions, one applying taxes, and the other not. 2. Open pos, select the FP that applies taxes, and add a product 3. Now apply a global discount of 10% 4. Chagne to the FP that does not apply any taxes. Notice that the discount line amount is still computed based on the the taxes from the old FP. Also, another "unrelated" bug, when adding products, the global discount was not always updating. Please see the individual commits' messages for more details on each fix. opw-5443716 Forward-Port-Of: odoo/odoo#247357 Forward-Port-Of: odoo/odoo#246387
6 changes
Resolved issues and error corrections
This update fixes a user experience issue where the 'Generate PDFs' button in the employee declaration list view only processed the currently visible records. Now, selecting 'Select All' reliably generates PDFs for all employee declarations, improving user clarity and efficiency. The fix also allows users to regenerate PDFs for existing documents.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232
This update fixes an issue where imported spreadsheets lost their connection to the original linked records. The change ensures that newly created spreadsheets maintain the same linked record as the source document during the import process, improving data consistency and workflow efficiency.
Original PR description
When importing an XLSX or CSV document into a spreadsheet, the linked record is lost on the newly created spreadsheet document. This happens because the conversion creates a new document through `copy()`, while `res_model` and `res_id` are computed fields and are not copied by default. This commit explicitly forwards the linked record values during the conversion so the created spreadsheet keeps the same linked record as the source document. Task: [6008920](https://www.odoo.com/odoo/project/2328/tasks/6008920) Forward-Port-Of: odoo/enterprise#110047
This update resolves an issue where multiple payment methods on a point-of-sale order caused errors. It now ensures that a customer is required when using receivable payment methods or cash payments exceeding 10,000 JOD, improving the reliability of transactions.
Original PR description
This commit fixes the following issues 1) Having more than one payment method on a pos.order led to an error 2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD task-6005832 Forward-Port-Of: odoo/odoo#255030 Forward-Port-Of: odoo/odoo#252631
This update fixes an error in how the cost of kit products is calculated when ordering multiple units on a purchase order. Previously, the cost was incorrectly displayed, leading to inaccurate inventory valuation. This change ensures accurate cost calculations for multi-unit kit purchases.
Original PR description
**Issue**: A PO of several units of kit product can lead to a wrong BOM cost **Steps to reproduce**: - Create a kit product (by creating a BOM) with AVCO valuation - Create a purchase order with 3…
**Issue**: A PO of several units of kit product can lead to a wrong BOM cost **Steps to reproduce**: - Create a kit product (by creating a BOM) with AVCO valuation - Create a purchase order with 3 units and a unit price of 10 - Confirm it and confirm the associated receipt - Go to the BOM of the kit product and check BOM overview -> The cost is 3.33 instead of 10 This also works with FIFO valuation **Cause**: While computing the value of the move: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L282 https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L313-L314 It checks the value of the PO: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/stock_move.py#L371-L372 Which relies on the `cost_ratio`: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_stock/models/stock_move.py#L221-L222 Which is computed this way: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/purchase_mrp/models/stock_move.py#L17 And does not take the number of received units into account. This means that the value of the move is 10 instead of 30, which makes the valuation computation wrong: https://github.com/odoo/odoo/blob/2e4a4f2d063f9b09263e6c137e1c04358020c668/addons/stock_account/models/product.py#L393 opw-5924940 Forward-Port-Of: odoo/odoo#249236
This update fixes an issue where stock valuations were inaccurate for users in different timezones. The change ensures that stock quantities are correctly calculated when a 'to_date' is selected, addressing a discrepancy in how dates are interpreted and converted.
Original PR description
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to…
**Issue** While performing stock valuation, when a `to_date` is selected, the resulting valuation may be incorrect depending on the user's timezone. **Steps to reproduce** - Set the user timezone to UTC+1 - Create a storable product with: - quantity: 10 (created today) - unit cost: 5 - valuation method: AVCO - Go to Accounting > Review > Inventory > Inventory Valuation - Select today's date - Click on "Ending Stock" -> The total value and quantity in stock are 0 instead of respectively 50 and 10. **Cause** When selecting a date (e.g. 12/04), the `to_date` is initially set at 00:00 in the user's timezone. An attempt is then made to convert it to 23:59 to avoid excluding quantities created during that day: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 However, this conversion is performed on a naive UTC datetime. For a user in UTC+1, this results in the following situation: - 12/04 00:00 (user timezone) -> 11/04 23:00 UTC - Converted to 23:59 UTC -> 12/04 00:59 in user timezone As a consequence, most of the quantities created on 12/04 are excluded from the valuation. This issue impacts AVCO (and FIFO as well), as `at_date` is used during cost computation: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock_account/models/product.py#L147-L150 In addition, `at_date` is added to the context, while `qty_available` relies on `to_date` instead: https://github.com/odoo/odoo/blob/87e176ad76c9d7b87cd622ae38a8b9a62813b1cb/addons/stock/models/product.py#L151-L153 This inconsistency leads to incorrect quantities and valuation results. opw-5491743 Forward-Port-Of: odoo/odoo#246163
This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential delays in production timelines.
Original PR description
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order…
**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#252654 Forward-Port-Of: odoo/odoo#240617
1 change
Resolved issues and error corrections
This update resolves an issue where multiple payment methods on a point-of-sale order caused errors. It now ensures that a customer is required when using receivable payment methods or cash payments exceeding 10,000 JOD, improving the reliability of the POS system.
Original PR description
This commit fixes the following issues 1) Having more than one payment method on a pos.order led to an error 2) Customer should be required if payment method is receivable, or cash with amount > 10,000 JOD task-6005832 Forward-Port-Of: odoo/odoo#255030 Forward-Port-Of: odoo/odoo#252631
1 change
Resolved issues and error corrections
This update resolves a critical issue where the WhatsApp integration would crash when a WhatsApp Business Account was linked to multiple phone numbers. The fix prevents the system from attempting to access security information from multiple account records, ensuring stable webhook processing for users with multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
2 changes
Resolved issues and error corrections
This update resolves a critical issue where the WhatsApp integration would crash when a WhatsApp Business Account was linked to multiple phone numbers. Odoo’s design allows for this, but the webhook processing logic was flawed, causing a security error. This fix ensures the WhatsApp integration remains stable and reliable for users managing multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180 Forward-Port-Of: odoo/enterprise#107134
This update fixes a usability issue where the 'Generate PDFs' button in the employee declaration list view only processed the currently visible records. Now, selecting 'Select All' reliably generates PDFs for all employee declarations, improving the user experience. It also allows users to regenerate PDFs for existing documents.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232