Daily updates from Odoo
Thursday, August 21, 2025
59 changes
20 changes
Resolved issues and error corrections
This fixes cases where messages or comments with attachments could behave incorrectly if a file was still uploading. Users are less likely to accidentally delete attachments or send incomplete messages in chat, mail, live chat, and course review flows.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620 Forward-Port-Of: odoo/odoo#223464 Forward-Port-Of: odoo/odoo#223367
This update brings the spreadsheet component to the latest version and fixes several user-facing issues. Users should see more reliable chart exports, cleaner copy-paste behavior, safer table row moves, and correct pivot refresh after undoing deletions.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d5eb3a626 [REL] 18.4.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d5eb3a626 [REL] 18.4.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/c25b8c6cb [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426) https://github.com/odoo/o-spreadsheet/commit/1c099dc42 [FIX] clipboard: don't paste both image and text content [Task: 4876682](https://www.odoo.com/odoo/2328/tasks/4876682) https://github.com/odoo/o-spreadsheet/commit/a593cb80a [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731) https://github.com/odoo/o-spreadsheet/commit/a74b221a4 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Restaurant point-of-sale orders are now reliably saved and synchronized when staff return to the floor screen after making edits. This prevents changes such as notes, customer details, quantities, prices, discounts, or pricelists from being missed across devices or sessions.
Original PR description
Previously, changes made to an order did not trigger synchronization when navigating back to the floor screen. These changes include: • Adding a note or customer note to a line or order • Setting a customer • Modifying quantity, price, or discount via the numpad • Setting a pricelist This commit ensures the order is marked as dirty, which triggers the sync when returning to the floor screen. task.4946929 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221292 Forward-Port-Of: odoo/odoo#220724
This fixes an issue where the online shop page could fail to load if all variants of a product template had been deleted. Customers and staff can now browse the shop without encountering an error caused by incomplete product variant data.
Original PR description
When a product template's variants are deleted, accessing the shop page raises an traceback. Steps to reproduce the error: - Install ``website_sale`` module - Enable Product Variants From Settings - Go to Website > eCommerce > Attributes > Open Color > On Product Cards: Visible > Add 2 Attribute values - Create a new Product Template > Attributes & Variants > Add Color attribute with 2 values - Delete the variants of this Product Template - Go to Website > Shop Traceback: ``IndexError: tuple index out of range`` https://github.com/odoo/odoo/blob/c7bedc25c9702956aab73cb6a0c0c544c062a3dd/addons/website_sale/models/product_template.py#L298 When a product template's variants are deleted, ``ptav.ptav_product_variant_ids`` becomes empty. The code tries to access the first element by index, causing the traceback. sentry-6801851377 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Selecting a record from the "Search more" dialog now correctly fills the field instead of unexpectedly opening the record form. This prevents confusion when choosing items such as purchase order lines and keeps the selection flow focused on completing the field.
Original PR description
Example of steps: - install web, purchase and studio - add a many2one with studio anywhere and choose purchase.order.line - close studio - try to use this new field, select "Search more" - select a random record - It opens the form view record instead of select It This is because purchase order line has an openAction that forces the opening of a form view. However, for a select_create_dialog, we must bypass this action to allow nothing except selection. To do this, a new prop has been added, “allowOpenAction,” in the list_controller, which will be true by default, but will be false for select_create_dialog. opw-4958121 Forward-Port-Of: odoo/odoo#223253 Forward-Port-Of: odoo/odoo#222602
Combo products now show the correct pricelist discount on product pages and during checkout. This prevents customers from seeing misleading crossed-out prices such as $0.00 and helps ensure discount information remains consistent through the buying flow.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848 Forward-Port-Of: odoo/odoo#223436 Forward-Port-Of: odoo/odoo#222472
This fixes incorrect duration calculations for employees on flexible schedules when attendance is recorded on a public holiday. Work entries now reflect the actual time gaps instead of incorrectly assigning a full 8-hour duration, improving payroll and time-off accuracy.
Original PR description
### Steps to reproduce: - Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours. - Create a public holiday with generic time off work entry type. - Create…
### Steps to reproduce: - Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours. - Create a public holiday with generic time off work entry type. - Create one or multiple attendances for marc demo on the public holiday. - Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h. ### Cause: This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day ### Fix: We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day opw-4887933 Forward-Port-Of: odoo/odoo#222646 Forward-Port-Of: odoo/odoo#218823
Editing the quantity on a validated receipt for products valued by lot no longer causes an unexpected crash. The system now guides users with an error when the lot information is ambiguous, helping prevent incorrect inventory valuation changes.
Original PR description
Steps to reproduce: 1) Create a product tracked by lot and with valuation by lot. 2) Create a Purchase Order with this product and Confirm it. 3) Go to Receipt 4) Add a Lot number and validate 3) Unlock the receipt and modify the `quantity`. Current behavior - Get a traceback. Expected behavior: - If there is only one lot: - update the lot quantity - Else : - raise an error The fix should be applied before the `web_save` call to prevent the creation of a new `stock.move.line`. Therefore it's done on the `onchange` call. opw-4841162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221620 Forward-Port-Of: odoo/odoo#213534
This fixes the Spanish VAT Model 303 report so operations covered by articles 22, 23, and 24 are included in box 60. Businesses using Spanish localization will get more accurate tax reporting and reduce manual correction needs.
Original PR description
Operations included in articles 22, 23 and 24 should be included in section 60 of the model 303 report: source: https://declarando.es/modelo-303/casillas-59-60-y-61? opw-4954870 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222549 Forward-Port-Of: odoo/odoo#221686
Event tickets sold through Point of Sale now keep their ticket-specific price when a customer is added or the pricelist changes. This prevents accidental price reductions to the base product price and helps ensure customers are charged the intended event ticket amount.
Original PR description
Before this commit: ========== - When selling event tickets through the Point of Sale (PoS), if an orderline was created with the ticket-specific price (higher than the base product price), the price would reset to the base product price when a customer (partner) was added or the pricelist was changed. After this commit: ========== - The event ticket orderline now retains its original ticket price even after a partner is selected or the pricelist is updated. This ensures pricing consistency and prevents unintended overrides for event-specific products. task-4862687 Forward-Port-Of: odoo/odoo#223549 Forward-Port-Of: odoo/odoo#214109
Time Off now uses the employee's active running contract when calculating working schedules and holiday days. This prevents incorrect balances when an employee has multiple contracts for the same period, such as a part-time active contract and a future full-time contract.
Original PR description
Steps: -Install the hr_holidays_contract module - Create two contracts for the same employee: - Contract A (Part-time) starting from 01/01/2025 and set to Running - Contract B (Full-time) also…
Steps: -Install the hr_holidays_contract module - Create two contracts for the same employee: - Contract A (Part-time) starting from 01/01/2025 and set to Running - Contract B (Full-time) also starting from 01/01/2025 and set to New - open holiday dashboard for that employee Description of the issue/feature this PR addresses: The Time Off dashboard incorrectly considers the full-time contract instead of the part-time one, even though the part-time contract is in the running state. Cause: The contract selection logic did not correctly prioritize the running contract when multiple contracts existed for the same period. Fix: This PR updates the logic to ensure that: - If a contract is in the running state at a given time, it is used to determine the working schedule and time off calculations. - If no contract is running during that time and multiple contracts exist, the contract with the latest creation_id will be considered. task-4724155 Forward-Port-Of: odoo/odoo#212959
Self-order prices now correctly include extra charges from all selected product options, including checkbox-style choices. This prevents customers from seeing or paying the wrong amount when ordering configurable items such as pizzas with size and topping options.
Original PR description
Currently, there is inconsistent behavior in price calculation when a user places a self order for a product containing attributes. **Pre-requisites:** - POS module installed and configured. -…
Currently, there is inconsistent behavior in price calculation when a user places a self order for a product containing attributes. **Pre-requisites:** - POS module installed and configured. - Variant enabled in settings. - Self-ordering is enabled in the POS configuration. - Two product attributes created in the settings/attributes: - One of type radio with variant creation set to Instantly. - Another of type multi-checkbox with variant creation set to Never. - Create attribute lines for both attributes with default extra prices. **Steps to reproduce:** 1) Create a product template linking the above attributes 2) Ensure the product is available in POS and self ordering 3) Open a POS session in one browser tab and the self-ordering in another. 4) Select the product in the self-ordering interface, first choosing an option for the radio attribute, then selecting one or more options for the multi-checkbox attribute. **Error:** You will see the difference between the expected price and the displayed price **Example for Clarity:** Consider a product called Pizza with 2 attributes. The base price of the pizza is $10. | Attribute | Option | Extra Price | | ----------------------------------- | ---------------- | --------------------- | | **Size** (radio) | Small (S) | \$0 (no extra charge) | | | Medium (M) | \$5 | | | Large (L) | \$10 | | **Extra Toppings** (multi-checkbox) | Veggies | \$3 | | | Extra Cheese | \$3 | | | Veggies & Cheese | \$5 | If the user selects a medium-sized pizza with veggie toppings, The expected price is: ``` $10 (base) + $5 (Medium size) + $3 (Veggies) = $18. However, the price shown is only $13. ``` **Root Cause:** For attributes of the multi-checkbox type, variant creation is set to Never by default. This means no product variants are generated for such attributes. Because of this, when calculating the price, the extra price associated with the multi-checkbox attribute is added directly to the base price of the product template instead of the price of the selected variant. This happens because the variant information is not properly passed to the price calculation method: https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/pos_self_order/static/src/app/services/card_utils.js#L187-L196 https://github.com/odoo/odoo/blob/9df334c0aca8a57dcbed4c87b43b18403f3a7c6e/addons/point_of_sale/static/src/app/models/product_template.js#L185-L189 As a result, the extra price for the multi-checkbox attribute is incorrectly added to the product template’s base price rather than the variant’s price. **Solution:** Pass the product_variant derived from the selected product.product to the price calculation method. This ensures that if a variant exists based on the user’s selection, the extra price is added to the variant’s price rather than the base product template price, resulting in the correct total price. opw-4963537 Forward-Port-Of: odoo/odoo#221375
Creating a draft journal entry from a payslip list filtered by pay run now keeps the correct company context. This prevents empty entries from being created in the wrong company and ensures payroll accounting entries are populated as expected.
Original PR description
Problem ---------- When you create a draft entry from the payslip list view filtered by payrun, it creates a empty journal entry in Company US instead of the current one. Objective ---------- Create a filled journal entry in the good company Solution ---------- The context of the payrun card component was empty. The context of the list controller is now transmitted to the Record Component to keep the same context task-4932712
This fixes an issue where Odoo Studio treated behind-the-scenes fields as editable items in views. Studio now keeps those fields available for data loading without showing them or letting them interfere with view editing, helping avoid incorrect layout changes.
Original PR description
…lly added since commit odoo/odoo@6f06420e4a9443c52dc0cb427f8f55eb4aecabce, fields that are present in expression but not in the arch are automatically added. This caused problems in Studio, where those were considered normal nodes, while they should only be there to tell the model what to fetch. This commit aims at not rendering those nodes in a way that prevent them from parasiting the computation of xpaths. opw-4981741 Forward-Port-Of: odoo/enterprise#92789 Forward-Port-Of: odoo/enterprise#92602
The accounting payment widget now correctly shows remaining bank statement amounts after partial reconciliation and applies the right currency conversion. This helps accountants match invoices to bank statement lines accurately and prevents unrelated invoice payments from being undone when one partial match is removed.
Original PR description
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the…
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the statement line - Duplicate the invoice and post it => First issue, you don't see the 100$ left on the statement line It's still reconciliable To fix that, we only remove fully reconciled statement lines. Second issue: - Have a bank journal in EUR with a rate of 2 - Make a statement line for 400€ in this journal - Create an invoice for the same partner of 100$ => The widget proposes a statement line of 400$ instead of a 200$ equivalent (with the rate conversion) The issue is that we convert with a foreign_currency_id that is not present in that case. To fix both, we change the way we compute the amount to always use the residual converted from the right currency [FIX] account_accountant: partial on statement line for invoice widget To reproduce: - Make a statement line for partner_a for 200 $ - Make 2 invoice for same partner for 100 $ - Reconcile them with the statement line (via the widget) - Unreconcile first invoice via the payment widget => The second invoice is also unreconciled To solve: Only unreconcile the lines that are part of the partial that we want to unlink Forward-Port-Of: odoo/enterprise#92005
Reloading the Point of Sale with the booking view selected no longer leaves users on a blank screen. The booking screen now opens automatically as expected, helping staff continue managing restaurant appointments without interruption.
Original PR description
**Before this commit**: When reload data in pos then booking tab is display blank. It is action method so need to call when component is called. **After this commit**: Booking view now correctly and automatically opens when the POS is loaded or reloaded with the `actionName=manage-booking` parameter. Task - 4873055
Fixed an issue where employees on flexible schedules could receive incorrect 8-hour work entry durations for short gaps on public holidays. Work entries now calculate durations from the actual period being regenerated, improving payroll and attendance accuracy.
Original PR description
### Steps to reproduce: - Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours. - Create a public holiday with generic time off work entry type. - Create…
### Steps to reproduce: - Set Marc Demo's contract work entry source to attendances and working schedule to flexible hours. - Create a public holiday with generic time off work entry type. - Create one or multiple attendances for marc demo on the public holiday. - Regenerate work entries for marc demo for that day, the gaps in between the attendances created and the working hours will be filled with work entries with the right start/end time but duration will always be 8h. ### Cause: This is happening because when getting the duration batch for the work entry we get the attendance intervals the employee should work in that period and if the employee is flexible we will get a fake attendance with the number of hours required per day ignoring if the period is just a small period of the day ### Fix: We are checking now since the start date not monday so we don't set a fixed week start. We check if the period is less than the remaining hours we get it as it mostly means that it is less than one day opw-4887933 Forward-Port-Of: odoo/enterprise#92193 Forward-Port-Of: odoo/enterprise#90163
Updating a company's address now also clears outdated map coordinates for related child contacts, preventing old or incorrect pins from staying visible. This helps users trust that Map View reflects the latest contact address information, with a known limitation for some import scenarios that can be corrected by resyncing the parent contact.
Original PR description
**Issue:** When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers **Cause:** The `partner_latitude` and `partner_longitude` fields were not reset…
**Issue:** When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers **Cause:** The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed **Fix:** We added a `partner_latitude` and `partner_longitude` reset when changing address in write We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude` We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields` **Limitations:** One issue remains during import: the parent-child address synchronization is disabled on contact creation This means children may be created with addresses different from the parent’s and have mismatch positions on Map This can be corrected by updating or re-importing the parent to trigger synchronization **Steps to reproduce:** With Form: - Add a parent contact company with a valid address - Add a child contact related to company, with a valid address - Open the Map View, both address must appear on Map - Modify the parent address to remove street (make it invalid) - Check that the child address match the parent one - Check the Map View, before the fix the child should remain with a wrong position With import: Create an import file (an example is in on the ticket) - Add a sheet for the Parent contact with an valid address - Add a sheet to add the Child contact with a parent_Id, with a valid address - Add a sheet to break the address on the parent, removing the street - Open the contacts app - Import the valid Parent and Child sheets (you need to select Related Company / External ID) - Add a filter to get your created contacts - Check the Map View (You should see both parent and child) - Import the Break parent sheet - Check that the child address match the parent one in the Form - Check the Map View, before the fix the child should remain with a wrong position A file can be found on the ticket with pre-made data **Technical notes:** The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication opw-4842910 Forward-Port-Of: odoo/enterprise#92658 Forward-Port-Of: odoo/enterprise#90392
The kitchen preparation display no longer crashes when an order is marked done in a setup with only one preparation stage. This improves reliability for restaurants using simplified kitchen workflows and avoids interruptions during service.
Original PR description
Currently, an IndexError traceback occurs when changing the order state in the preparation display if it contains only one stage. **Steps to reproduce this issue:** 1) Install POS, Kitchen Display 2)…
Currently, an IndexError traceback occurs when changing the order state in the preparation display if it contains only one stage. **Steps to reproduce this issue:** 1) Install POS, Kitchen Display 2) Create a preparation display by removing all but one stage in the prep settings. 3) Open a restaurant session and create an order. 4) Open the preparation display and mark the created order as DONE. 5) A traceback will occur **Error:** ``` IndexError: tuple index out of range ``` **Cause:** When the Done button is clicked in a preparation display with only one stage, an ORM call to `change_state_status` is triggered. This then calls `_record_status_change_prep_time`, followed by `is_stage_position`. https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_state.py#L31-L40 https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_stage.py#L21-L22 In `is_stage_position`, static positions [0, -1, -2] are used to access items in the `stage_ids`. If only one stage exists, accessing indices -2 results in an IndexError. **Solution:** Before accessing a stage by position, check that the length of stage_ids is greater than or equal to the absolute value of the position. This prevents attempts to access out-of-range indices. opw-4985306 Forward-Port-Of: odoo/enterprise#91918
Users editing spreadsheet global filters now see the selected filter panel replace the existing side panel instead of piling up a second panel. This prevents broken Cancel or Remove actions and makes filter management more reliable.
Original PR description
Steps to reproduce: - Open the global filter side panel (list of all filters) - Pin the panel - Click on a specific filter to view/edit it Current behavior before PR: - A second side panel was opened instead of replacing the current one - Clicking 'Cancel' on the new panel had no effect - Clicking 'Remove' caused a traceback Desired behavior after PR is merged: - The new side panel replaces the current one (main or secondary) - The previous panel is restored correctly on 'Cancel' or 'Remove' - If the new panel is already open, we simply close the current one Task: [4911603](https://www.odoo.com/odoo/2328/tasks/4911603)
11 changes
Resolved issues and error corrections
The Attendance overview list now shows employees only when they have matching attendance records. This avoids clutter and makes grouped attendance reports easier for HR teams to read, while preserving the existing Gantt view behavior.
Original PR description
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees…
To reproduce: ============= - Activate the "Attendances" app. - Go to Attendances > Overview. - Switch to list view. - Group by Employee. Issue: ====== The current domain fetches all employees matching the filter, regardless of whether they have attendance entries in the grouped model. https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/addons/hr_attendance/models/hr_attendance.py#L677 Fix: ==== Restrict the employee list to only those linked to a resource that appears in the grouped data https://github.com/odoo/odoo/blob/5b5f0bf795ca538e91f063f2b3185c12b1d0a992/odoo/models.py#L2360-L2361 The problem is the behavior of gantt view will change it's behavior So we have to applied only to the list. there's something unique when we call it from the gantt which is `gantt_start_date` property that we will use it so we can differentiate between list and gantt view -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223594 Forward-Port-Of: odoo/odoo#223181
Online-paid self-order POS orders are now sent to the preparation display, matching the behavior of terminal-paid orders. This prevents kitchen or preparation teams from missing orders that customers already paid for online.
Original PR description
After this pr: https://github.com/odoo/odoo/pull/213493 the orders were not sent to the preparation display if the order was payed with and online payment method. This commit add the same logic as the terminal payments to send the order to the preparation display. 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
Fixes an issue where payment methods set up in a parent company were not visible when viewing a contact from a child branch. This ensures branch users can see and use the expected payment details without switching company context.
Original PR description
In this bug, the payment method is not shown in the child branch. To reproduce: 1- Create a db with account and contact app installed 2- Create a company and a branch 3- Create a payment method in parent company and add it to contact form of a partner 4- Go to child branch. You can see the payment method is not shown in the contact form. opw-4920219 Forward-Port-Of: odoo/odoo#223598 Forward-Port-Of: odoo/odoo#219448
This update refreshes Odoo Spreadsheet with several fixes that improve everyday reliability. It corrects chart exports to Excel, avoids duplicate pasted content from the clipboard, prevents inconsistent table row moves, and restores pivot data properly after undoing deletions.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ab02b0cb9 [REL] 18.3.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ab02b0cb9 [REL] 18.3.17 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0d2a01e6c [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426) https://github.com/odoo/o-spreadsheet/commit/4d2398b70 [FIX] clipboard: don't paste both image and text content [Task: 4876682](https://www.odoo.com/odoo/2328/tasks/4876682) https://github.com/odoo/o-spreadsheet/commit/7f80875f3 [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731) https://github.com/odoo/o-spreadsheet/commit/64cf69dc0 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes cases where files could be acted on before their upload was fully recognized, which could cause attachments to delete without confirmation or block messages from sending. It improves reliability when adding files in chat, messaging, live chat, and course review workflows.
Original PR description
\* = im_livechat, website_slides Not waiting for the uploading state to be resolved can lead to unexpected behavior, such as deleting the attachment immediately when clicking on the delete button rather than showing the confirm dialog. This might also prevent the composer from being sent if the attachment is still uploading. This is checked when checking the enabled state of the send button when clicking on it, but it is not checked when pressing enter directly. Some tests also checked uploading was finished but didn't target the correct attachment. https://runbot.odoo.com/odoo/error/230901 https://github.com/odoo/enterprise/pull/92620 Forward-Port-Of: odoo/odoo#223464 Forward-Port-Of: odoo/odoo#223367
Shared Microsoft Office documents now keep the correct file type instead of being treated as ZIP files. This lets portal users open and work with documents in Odoo features such as spreadsheets without file type errors.
Original PR description
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3.…
Issue: Inconsistent mimetype vs filename for documents shared by portal users. 1. Share a ms office document logged in as a portal user. 2. filename is correct, but mimetype is `application/zip`. 3. User can't interact with the file to open the file in the Odoo spreadsheet because the mimetype is zip. <img width="387" height="192" alt="image" src="https://github.com/user-attachments/assets/be31f05f-e4e3-44d9-b12a-66f96feba950" /> <img width="274" height="67" alt="image" src="https://github.com/user-attachments/assets/93064e5c-c028-41ce-8e79-1b9c9447c018" /> With `fix_filename_extension()`, the following two commits fixed the issue of Odoo's `guess_mimetype` function incorrectly guessing extensions such as `.xlsx` as `.zip` extension. https://github.com/odoo/odoo/commit/8842b6b43e7c3d1cc67d7d399bb210e4009e23b2 https://github.com/odoo/odoo/commit/34d9375e2efb604f8e7036cb710f44b01f9ccaee However, the `_from_request_file()` still uses the incorrectly guessed mimetype to create an attachment, leading to inconsistent extension from the filename (.xlsx) vs attachment record's mimetype (.zip). This commit fixes the issue by using the mimetype from the filename's extension. This is safe if the following assumption is correct: At the point where the `from_request_file()` attempts to create the attachment record, the `filename` contains correct extension name, presumably fixed by the `fix_filename_extension()`. Commit message to be changed after with Julien's confirmation; opw-4753670 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222556 Forward-Port-Of: odoo/odoo#222368
Combo product discounts now display correctly when a pricelist discount applies, both on the product page and during checkout. This prevents customers from seeing confusing crossed-out zero prices or missing discounts, improving pricing clarity in eCommerce flows.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848 Forward-Port-Of: odoo/odoo#223436 Forward-Port-Of: odoo/odoo#222472
Employee clock-in updates in Belgian POS now include the required staff identification field when shared with other devices. This prevents errors when another device receives the update and needs to communicate with the Belgian fiscal blackbox.
Original PR description
Before this commit, when clocking, the session was synchro with other devices but without the _employee_insz_or_bis_number custom field. _employee_insz_or_bis_number was thus not accessible after the device receives the websocket message and the pos was returning a traceback when trying to send a message to the blackbox. This commit fixes the issue.
Receipt validation now correctly triggers automatic lot or serial number label printing after a quality check is passed. This prevents missing label downloads when incoming products require quality checks, helping warehouse teams complete receiving flows without manual reprints.
Original PR description
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The…
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action ## Cause: The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close' ## Note: The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option ## Steps to reproduce: - Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts - Create a Product tracked by Unique Serial Number - Add a Quality Check for the Receipts operation - Create a New Receipt for the product - Mark as Done and Add the Serial Number - Validate the receipt and Pass the check - Before the fix, no document was downloaded opw-4790427 Forward-Port-Of: odoo/enterprise#90134
Odoo Studio now ignores automatically added helper fields when displaying and arranging views. This prevents invisible technical fields from interfering with layout calculations, making Studio edits more reliable for users.
Original PR description
…lly added since commit odoo/odoo@6f06420e4a9443c52dc0cb427f8f55eb4aecabce, fields that are present in expression but not in the arch are automatically added. This caused problems in Studio, where those were considered normal nodes, while they should only be there to tell the model what to fetch. This commit aims at not rendering those nodes in a way that prevent them from parasiting the computation of xpaths. opw-4981741 Forward-Port-Of: odoo/enterprise#92751 Forward-Port-Of: odoo/enterprise#92602
Fixes an issue where closing a POS register could fail if an invoice selected for settlement was paid elsewhere at the same time. This helps cashiers close sessions reliably and avoids disruption from already-paid invoices.
Original PR description
This error occurs when attempting to settle an invoice in POS that has already been paid. Steps to reproduce: --- - Install `pos_settle_due` module - Create a new Invoice with Customer(eg: Billy Fox)…
This error occurs when attempting to settle an invoice in POS that has already been paid. Steps to reproduce: --- - Install `pos_settle_due` module - Create a new Invoice with Customer(eg: Billy Fox) and Confirm - Open `Bakery Shop` > Add Product > Select Customer(eg: Billy Fox) and `Settle Invoices` > Select the Invoice you created > Make payment - In another Tab, `Pay` the Invoice you created - Close Register Traceback: --- `TypeError: 'bool' object is not subscriptable` At [1], this error occurs because `inv.invoice_outstanding_credits_debits_widget` is set to `False`. This happens because, at [2], the condition `move.payment_state` evaluates to True, allowing the code to continue execution. As a result, `inv.invoice_outstanding_credits_debits_widget` remains False. [1]- https://github.com/odoo/enterprise/blob/95567f106fba3ed6d334ce6ad523378239865204/pos_settle_due/models/pos_session.py#L18-L21 [2]- https://github.com/odoo/odoo/blob/e61d55c6bf8afaef37d813a702438cb96baeddb1/addons/account/models/account_move.py#L1324-L1327 sentry-6628404004
8 changes
Resolved issues and error corrections
Fixed a point of sale preparation display issue that could cause an error when a restaurant used only one preparation stage. Staff can now mark that single stage as Reset or Done without the preparation screen crashing, improving reliability for simpler kitchen workflows.
Original PR description
This error occurs when we try to mark a single stage as `Reset` or `Done` in the preparation display. Steps to reproduce: --- - Install the `pos_restaurant` module - Create a New `Preparation Display` with one stage - Open `Preparation Screen` - Now `Reset` or `Done` the stage in the other tab Traceback: --- `IndexError: tuple index out of range` At [1], an error occurs because it tries to access a `position` that doesn't exist in the tuple. This happens because at [2], the code attempts to retrieve the second-to-last (-2) stage position, but only one stage is being used. [1]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_stage.py#L21-L22 [2]- https://github.com/odoo/enterprise/blob/285cca92a52f7b79de1d020558aa9b116cd7e44a/pos_enterprise/models/pos_prep_state.py#L72 sentry-6681171781 Forward-Port-Of: odoo/enterprise#87098
The Kitchen Display no longer crashes when an order is marked done on a preparation display that has only one stage. This keeps restaurant order workflows running smoothly for setups with simplified preparation stages.
Original PR description
Currently, an IndexError traceback occurs when changing the order state in the preparation display if it contains only one stage. **Steps to reproduce this issue:** 1) Install POS, Kitchen Display 2)…
Currently, an IndexError traceback occurs when changing the order state in the preparation display if it contains only one stage. **Steps to reproduce this issue:** 1) Install POS, Kitchen Display 2) Create a preparation display by removing all but one stage in the prep settings. 3) Open a restaurant session and create an order. 4) Open the preparation display and mark the created order as DONE. 5) A traceback will occur **Error:** ``` IndexError: tuple index out of range ``` **Cause:** When the Done button is clicked in a preparation display with only one stage, an ORM call to `change_state_status` is triggered. This then calls `_record_status_change_prep_time`, followed by `is_stage_position`. https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_state.py#L31-L40 https://github.com/odoo/enterprise/blob/39810b5b7df01f381a08582ddc0c5218e99c964c/pos_enterprise/models/pos_prep_stage.py#L21-L22 In `is_stage_position`, static positions [0, -1, -2] are used to access items in the `stage_ids`. If only one stage exists, accessing indices -2 results in an IndexError. **Solution:** Before accessing a stage by position, check that the length of stage_ids is greater than or equal to the absolute value of the position. This prevents attempts to access out-of-range indices. opw-4985306 Forward-Port-Of: odoo/enterprise#91918
Contact map locations now stay in sync when a company's address changes, preventing outdated markers for related child contacts. This helps users trust the Map View when maintaining customer or company address data, though a known import edge case may still require re-importing or updating the parent contact.
Original PR description
**Issue:** When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers **Cause:** The `partner_latitude` and `partner_longitude` fields were not reset…
**Issue:** When adding contacts with incorrect address data, the Map View could display outdated or incorrect markers **Cause:** The `partner_latitude` and `partner_longitude` fields were not reset for child contacts when the parent’s address changed **Fix:** We added a `partner_latitude` and `partner_longitude` reset when changing address in write We added `partner_latitude` and `partner_longitude` in the _address_fields to update the value each time it can be required, like on address change or contact creation The extension in the _address_fields is there to detect the changes on children synchronization, because it only replace the value that where present in vals for the fields in that list In that way, it will detect more address changes and trigger the write for the children with the corresponding parent `partner_latitude` and `partner_longitude` We also make sure that those extra _address_fields will not be displayed in the formatted address by removing them from `_formatting_address_fields` **Limitations:** One issue remains during import: the parent-child address synchronization is disabled on contact creation This means children may be created with addresses different from the parent’s and have mismatch positions on Map This can be corrected by updating or re-importing the parent to trigger synchronization **Steps to reproduce:** With Form: - Add a parent contact company with a valid address - Add a child contact related to company, with a valid address - Open the Map View, both address must appear on Map - Modify the parent address to remove street (make it invalid) - Check that the child address match the parent one - Check the Map View, before the fix the child should remain with a wrong position With import: Create an import file (an example is in on the ticket) - Add a sheet for the Parent contact with an valid address - Add a sheet to add the Child contact with a parent_Id, with a valid address - Add a sheet to break the address on the parent, removing the street - Open the contacts app - Import the valid Parent and Child sheets (you need to select Related Company / External ID) - Add a filter to get your created contacts - Check the Map View (You should see both parent and child) - Import the Break parent sheet - Check that the child address match the parent one in the Form - Check the Map View, before the fix the child should remain with a wrong position A file can be found on the ticket with pre-made data **Technical notes:** The reset logic is duplicated from the `base_geolocalize` module, because this module is optional and may not be installed in all cases Since `base_geolocalize` is not always present, its `write` override will not be triggered consistently On the other hand, `web_map` is automatically installed with the Enterprise version of Odoo Therefore, it is necessary to implement this fix in at least one of the two modules to ensure the behavior is active when Enterprise is used We chose to keep the override in both `base_geolocalize` and `web_map` to cover both Community and Enterprise cases reliably An alternative approach would be to move the reset logic directly into `res.partner` in the `base` module, making it always available regardless of installed addons and avoiding the duplication opw-4842910 Forward-Port-Of: odoo/enterprise#92658 Forward-Port-Of: odoo/enterprise#90392
Swedish SIE4 accounting imports now continue even when the file does not include previous-year information, avoiding an import crash. The importer also retries with an alternate text encoding when needed, helping customers process more client-provided files successfully.
Original PR description
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import…
**Issue**: Importing a SIE4 file without previous year information causes a traceback. **Steps to reproduce**: - Go to Accounting > Settings > Import - Import SIE 4 file - Check the box "Import account opening balances" - Select the right xml and observe the traceback **Cause**: The method `_prepare_sie4_opening_balance_move` tries to directly access the previous year: https://github.com/odoo-dev/enterprise/blob/6d4919658650a006c73d4aaf1f500d67723dda0d/l10n_se_sie4_import/wizard/import_wizard.py#L376C9-L376C58 This results in a traceback when the previous year is not present. **Solution**: Make `_prepare_sie4_opening_balance_move` more permissive by falling back to the day before the first day of the current year if the `-1` section is not there. **Additional Notes**: The client file does not support `UTF8` format, retry with the `ISO-8859-1` format in case of `UnicodeDecodeError`. opw-4894495 Forward-Port-Of: odoo/enterprise#92174 Forward-Port-Of: odoo/enterprise#89425
Files added through the email wizard when sending a Sign request are now included in the outgoing email. This prevents recipients from missing documents that users intentionally attached, restoring expected email behavior.
Original PR description
Issue: * When users added attachments in the mail wizard (e.g., from the Sign module), the files were saved in the backend but not included in the outgoing email. Steps to Reproduce: 1. Edit a Sign template and click the Send button. 2. In the wizard, click on the Attachments button and select a file. 3. Press Send. 4. The email is sent, but the selected attachment is missing from the Sign request mail. Fix: * Adjusted the logic to correctly include attachments added through the wizard in the final email. Impact: * Users can now successfully send attachments added via the mail wizard. * Restores expected behavior and prevents missing documents in email. task-5002652 Forward-Port-Of: odoo/enterprise#91975
Users without shipping method administration rights can now request DHL shipping rates without hitting an access error. This keeps the quotation flow working smoothly when adding DHL delivery costs.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have DHL (legacy) as a delivery method; 2. log in as demo user; 3. create a quotation with a shippable product; 4. click "Add shipping"; 5. select DHL; 6. click "Get rate". Issue ----- > Access Error: > You do not have enough rights to access the field "dhl_account_number" on Shipping Methods (delivery.carrier). Cause ----- The error gets thrown in the `_set_dct_bkg_details` method. In previous versions, the `dhl_account_number` field would still be in cache after `srm.check_required_value` was called, as this method checks whether the `carrier.dhl_account_number` field is non-empty in sudo mode. As of saas-18.3, field access is checked even if the value is available in cache, resulting in the access error. Solution -------- Use `sudo` to retrieve the `dhl_account_number`. opw-4899776 Forward-Port-Of: odoo/enterprise#92557
The accounting payment widget now shows remaining bank statement balances correctly after partial reconciliation and applies the right currency conversion. It also prevents unrelated matched invoices from being undone when one partial payment is unreconciled, improving reliability for accounting teams.
Original PR description
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the…
[FIX] account_accountant: fix multi_currency payment_widget To reproduce: - Make a statement line for partner_a for 200 $ - Make an invoice for same partner for 100 $ - Reconcile it with the statement line - Duplicate the invoice and post it => First issue, you don't see the 100$ left on the statement line It's still reconciliable To fix that, we only remove fully reconciled statement lines. Second issue: - Have a bank journal in EUR with a rate of 2 - Make a statement line for 400€ in this journal - Create an invoice for the same partner of 100$ => The widget proposes a statement line of 400$ instead of a 200$ equivalent (with the rate conversion) The issue is that we convert with a foreign_currency_id that is not present in that case. To fix both, we change the way we compute the amount to always use the residual converted from the right currency [FIX] account_accountant: partial on statement line for invoice widget To reproduce: - Make a statement line for partner_a for 200 $ - Make 2 invoice for same partner for 100 $ - Reconcile them with the statement line (via the widget) - Unreconcile first invoice via the payment widget => The second invoice is also unreconciled To solve: Only unreconcile the lines that are part of the partial that we want to unlink Forward-Port-Of: odoo/enterprise#92334 Forward-Port-Of: odoo/enterprise#92005
This fix stops automatically added helper fields from being displayed or treated as editable elements in Odoo Studio. It prevents incorrect layout calculations and editing issues, making Studio views behave more reliably for users.
Original PR description
…lly added since commit odoo/odoo@6f06420e4a9443c52dc0cb427f8f55eb4aecabce, fields that are present in expression but not in the arch are automatically added. This caused problems in Studio, where those were considered normal nodes, while they should only be there to tell the model what to fetch. This commit aims at not rendering those nodes in a way that prevent them from parasiting the computation of xpaths. opw-4981741 Forward-Port-Of: odoo/enterprise#92789 Forward-Port-Of: odoo/enterprise#92602
20 changes
Resolved issues and error corrections
This fixes an issue where some sales orders with tracked products could not be properly brought into the Point of Sale when stock movements had not yet been created. Staff can now settle those orders in PoS more reliably, avoiding checkout interruptions for affected sales.
Original PR description
Before this commit, if an order was not confirmed and stock moves were not created, if products are tracked, the order lines would not be added to the PoS. opw-5026892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents zero-priced lines on credit notes from being exported with a misleading negative zero price. It helps ensure UBL electronic credit notes, including Romanian CIUS-RO files, pass validation and can be sent successfully.
Original PR description
**Issue description:** When creating a UBL credit note, a line with a zero unit price and a negative quantity would have its gross unit price calculated as `0.0 / <negative_qty>`. This results in a negative zero `-0.0`, which is considered an invalid negative net price by some EDI validators (e.g., Romanian CIUS-RO), causing the file to be rejected. **Steps to reproduce:** 1. Create a Sales Order with two lines: one product for €100 and a second (e.g., a delivery service) for €0. 2. Create and pay a downpayment invoice for a fixed amount greater than the order total, e.g., €200. 3. Go back to the Sales Order and create a "Regular Invoice". This will generate a credit note with negative quantities on the lines. 4. Ensure the journal is configured for UBL export (e.g., CIUS-RO). 5. Post, then send the credit note and inspect the generated XML file. The zero-priced line will show `cbc:PriceAmount = '-0.0'`. opw-5000314 Forward-Port-Of: odoo/odoo#223074
This fixes the setup of two Spanish 0% sales taxes so they are correctly treated as exempt with the right legal exemption reasons. It also removes older duplicate exempt tax entries that are no longer needed, helping Spanish invoices and tax reports use the correct classification.
Original PR description
Currently 2 sales taxes are misconfigured.
They both should be marked as 'exento' ("Exento") instead of 'no_sujeto_loc' ("No Sujeto por reglas de Localization")
- "0% EU G"; with "Exempt Reason" E5 / "Art. 25"
- "0% EX G"; with "Exempt Reason" E2 / "Art. 21"
This commit updated those taxes
Due to this the following sales taxes become obsolete.
- "VAT Exempt (Art. 21)"
- "VAT Exempt (Art. 25)"
They are deleted in this commit.
opw-4850585
Forward-Port-Of: odoo/odoo#223603Timesheet entries are now correctly connected to down payment invoices created from sales orders. This makes invoice grouping and reporting more accurate for services billed from tracked time.
Original PR description
To reproduce: ============= - create service product based on timesheet that creates project/task - create sale order with this product - confirm sale order - record couple hours on the task - go back to sale order and create downpayment invoice - go back to timesheet and group by invoice - you will see that the timesheet is not linked to the downpayment invoice Problem: ======== - before this commit, we only link timesheet to regular invoices, not to downpayment invoices. - the `_link_timesheets_to_invoice` method fetches timesheets from the SOL linked to the created invoice, which is in case of downpayment a different SOL than the one linked to the timesheet. Solution: ========= we call `_link_timesheets_to_invoice` in case of downpayment invoices and we also ensure that the method fetches the timesheets from all SOLs on the whole sale order. opw-4850089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how Odoo matches debit and credit lines during reconciliation when multiple partners are involved. Matching lines by partner produces cleaner, more accurate reconciliation details behind the scenes and avoids confusing residual amounts.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 1000 | 0 | | Account X | Partner A | 0 | 1000 | 2) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 1001 | 0 | | Account X | Partner B | 0 | 1001 | 3) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 1002 | 0 | | Account X | Partner C | 0 | 1002 | 4) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 0 | 1002 | | Account X | Partner C | 1002 | 0 | 5) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 0 | 1001 | | Account X | Partner B | 1001 | 0 | 6) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 0 | 1000 | | Account X | Partner A | 1000 | 0 | - Go to "Accounting / Accounting / Journals / Journal Items" - Select the 6 created lines linked to the Receivable Account - Reconcile them **Issue:** The 6 lines are fully reconciled, but when checking the amounts of the partial reconcile records (not visible in the UI), the debit and credit amounts are matched by their actual order. So, the first debit line of 1000 is matched with the first credit line of 1002, which results in a residual credit of 2 that is then matched with the second debit line of 1001, which leads to a residual debit of 999 and so on. This generates weird amounts in the partial reconcile records. **Solution:** In the case there are several lines with different partners, the lines can be sorted by partner to try to match the lines with the same partner together. opw-449356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Partial payment links for invoices now correctly request only the partial amount selected, rather than the full invoice total. This prevents customers from being asked to overpay when using a payment link.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an unpaid invoice; 2. generate a partial payment link; 3. open partial payment link; 4. click the Pay button. Issue ----- The invoice's full amount gets requested. Cause ----- Commit 5697493e0091 added `amount` as a named keyword parameter in an `_invoice_get_page_view_values` override, but failed to pass it along to the call to `super`. As the base method no longer receives an `amount` parameter, it defaults to the invoice total. Solution -------- Pass `amount` to the `super` call. opw-5013044
This update refreshes the spreadsheet component and fixes several issues affecting exports and data interactions. Users should see more reliable chart exports, safer table row handling, and better pivot behavior when undoing deletions.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6051c9e [REL] 18.0.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6051c9e [REL] 18.0.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e95196363 [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426) https://github.com/odoo/o-spreadsheet/commit/f55d9f356 [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731) https://github.com/odoo/o-spreadsheet/commit/94acb2343 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Point of Sale order searches by tracking number now use the correct session information. This helps staff find the right orders reliably, including orders from different sales sessions.
Original PR description
Before this commit, searching for an order by `tracking_number` matched against the `pos_reference` field. However, the `tracking_number` is constructed using the `session_id`, not the `pos_reference`. This mismatch could cause orders from other sessions to be not found, as the session id related part of the `tracking_number` may not align with the `pos_reference`. This commit fixes the issue by adjusting the search logic to match against the `session_id` instead, ensuring accurate results when looking up orders by `tracking_number`. opw-4934482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where employee organization charts could behave incorrectly when an employee had more than five managers. The chart now refreshes before the employee record is saved, giving users a more accurate view while editing employee details.
Original PR description
A buggy behavior when there are more than 5 managers was fixed. The org chart now updates before the employee record is saved. task-4609465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223453 Forward-Port-Of: odoo/odoo#216940
Fixes an issue where removing text color or formatting in the HTML editor could cause the editor to freeze in certain cases. This improves editing reliability, especially when formatting is applied to larger text blocks or protected content is selected.
Original PR description
**Current behavior before PR:** - When color was applied to a block-level element, attempting to remove it caused the `removeFormat` method to enter an infinite loop. - Removing formatting on a contenteditable false element infinite loop when removing format. **Desired behavior after PR is merged:** - Now, the color is correctly removed from the selected text, even when it is applied to a block-level element. - Now, the toolbar no longer opens when the selected element is contenteditable false task: 4575459
This fix restores an optimization that avoids unnecessary reading of full image data when only file size information is needed. It improves performance in image-heavy views such as product kanban, especially for systems using slower external storage.
Original PR description
Since 7744886d6141ca7971d91807d0444c707e10fdf8, reading binary field with bin_size=True still reads the ir.attachment datas field, which is relatively slow with some storage backends. In the products kanban view this can easily add 1 sec to web_search_read, if there is a 10ms latency when reading images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Payment links generated from invoices now correctly apply the custom amount entered by the user. This prevents customers from seeing or paying an unexpected amount when opening the link.
Original PR description
Steps to reproduce: 1. Create an invoice with an amount. 2. Post the invoice. 3. Generate a payment link with a custom amount. 4. Open the link. Issue: The generated link did not respect the amount…
Steps to reproduce: 1. Create an invoice with an amount. 2. Post the invoice. 3. Generate a payment link with a custom amount. 4. Open the link. Issue: The generated link did not respect the amount provided. Cause: In `account`, the method `_invoice_get_page_view_values` retrieves `amount` from `kwargs`. However, in `account_payment`, the overridden `_invoice_get_page_view_values` was incorrectly declaring `amount` as a method parameter instead of leaving it in `kwargs`. As a result, it was not passed to `super()`. This caused the amount from the link to be ignored. Solution: Remove `amount` from the method parameters, keep it inside `kwargs`, and then clean it up in `_get_common_page_view_values` to avoid multiple arguments error when retrieving the payment providers. Note: This issue was found while preparing the Pull Request [#218243](https://github.com/odoo/odoo/pull/218243). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an accounting issue where switching an invoice from a foreign currency to the company currency and back before saving could incorrectly apply exchange rates to journal item amounts. Businesses can now rely on invoice line balances remaining accurate when users adjust currency selections during invoice entry.
Original PR description
Steps to reproduce: - Enable a foreign currency with rate - Create an invoice in foreign currency - Switch to company currency, then back to foreign currency before saving - Check journal items values Issue: Amount currency and balance have been affected by the currency rate even if the original currency was restored before saving opw-4864994
This fixes Turkish e-Dispatch XML generation so the delivery customer is taken from the main commercial partner, while the delivery address remains the actual delivery contact. It also uses the appropriate customs ZIP for non-Turkish customers and hides XML generation when no delivery address is available, helping avoid incorrect or invalid dispatch documents.
Original PR description
Behaviour before this commit: - Previously, the picking partner was used for sending both the Delivery Customer and delivery address in the XML. - Secondly, ZIP was used in Delivery Customer regardless of the country of the partner (Turkish or Non-Turkish) Desired behaviour after this commit: - After this commit, the commercial partner of the picking partner will be used for sending the Delivery Customer data and picking partner itself will be used for sending the Delivery Address in the XML. - Additionally, if the commercial partner is non turkish, customs ZIP will be used in the Delivery Customer in the XML. - If the delivery is validated without giving Delivery Address, then the 'Generate e-Dispatch (XML)' button will be hidden. TaskID:4918748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218096
The French point of sale certification report now avoids loading unnecessary order data when running its inalterability checks. This reduces memory consumption significantly for businesses with large sales volumes, helping the report complete more reliably.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#222416
Employees assigned to a global working schedule now correctly receive timesheet entries for public holidays. This prevents missing timesheet records when a working schedule is shared across companies rather than tied to one company.
Original PR description
_*= project_timesheet_holidays Steps to Reproduce: --------------------------- 1. Create a global working schedule (company should be False). 2. Assign this working schedule to any employee. 3. Create a public time off (for all the working schedule). 4. You will notice that the timesheet entry is not generated for the public holiday for that employee. Issue: ------------------------------- - Employees who use the WS without a company are excluded from timesheet creation. Cause : -------------------------------- - When grouping employees by calendar global WS (with no company) were being excluded. - And the timesheets were not generated due to the check `calendars_dict[calendar_id].company_id != company` when the WS had no company Fix: ------------------ - We will add the domain to include the global WS and and we will check if the the WS has company id then only check the condition. task-4900941
This fix ensures the invoice posting time matches the official CFDI timestamp used for Mexican electronic invoicing. It also keeps record locking intact during sending, reducing the risk of timing-related inconsistencies.
Original PR description
`fecha_datetime` could be set to a different value than the `document_post_time` passed as parameter because of the `min`. We also must revert the `_cr.commit` during the sending because it removes the lock on records. Instead we set the invoice post time and commit before locking. task-none
Fixes an accounting reconciliation issue where matching an invoice and a vendor bill from different partners could assign the wrong partner to the generated transfer lines. This helps keep partner ledgers and related accounting reports accurate in workflows where customer invoices and vendor bills are reconciled together.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#89972
Fixed an issue where products split into packages during barcode batch transfers could be assigned to the wrong transfer. This ensures each transfer records the correct delivered quantities, preventing incorrect stock movements and unnecessary backorders.
Original PR description
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" -…
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" - create two storable product with an on hand quantity of 10 - create a an internal transfer for the first product for a qty of 10 - mark it as to do - do the same for the second product and make sure that it's the same contact - open barcode and select batches - select the last batch created - scan WH-STOCK - enter and confirm a quantity of 4 for each line - click on put in pack (at this step we can already see that the two new lines created are associated wit the second picking, even though it should be one line per picking) - click on the +6 on each line and click on put in pack - validate **Current behavior:** - a back order has been created for the first picking - the first internal transfer has only delivered 4 units of the first product - the second internal transfer has delivered 10 of the second product and 5 of the first product **Expected behavior:** both pickings should have delivered 10 of their product **Cause of the issue:** The lines created when clicking on "put in pack" for the first time are both associated with the second picking because the line split: https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514 and the picking_id of the new line is set to the values provided by the `_getNewLineDefaultValues` as the picking_id of the last selected `line`: https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281 rather than from the values of the initial line it is split from. opw-4952964 Forward-Port-Of: odoo/enterprise#91378
This fix prevents Belgian payroll accounting setup from failing when a specific mobility budget salary rule is missing. It helps companies complete accounting installation even if the rule was deleted or their database was created before the rule existed.
Original PR description
Currently an issue occurs when the user tries to install `10n_be_hr_payroll_account/account` after follow steps: - Install `l10n_be_hr_payroll` and switch to `BE Company CoA` - Go to Payroll > Configuration > Salary > Rules - Delete `Mobility Budget Special Contribution` - Error occurs when trying to install accounting error: `ValueError: External ID not found in the system: l10n_be_hr_payroll.cp200_employees_salary_mobility_budget_tax` The salary rule mentioned above steps was added with commit [1], and the issue also occurs if the database was created before commit [1] with a module `l10n_be_hr_payroll` and the user tries to install the account after commit [1]. This commit fixes the issue by using `raise_if_not_found=False`, which prevents an error from being raised when the salary rule is missing. [1] - https://github.com/odoo/enterprise/commit/16c8a223beda4e4ebcf2c24f716687726f7230f3 sentry-6578747340