Daily updates from Odoo
Thursday, November 13, 2025
36 changes · 18.0
New functionality added to Odoo
This change adds a new module to create and send electronic delivery guides (e-Remitos) for Uruguay from stock delivery orders. It helps businesses comply with local tax requirements by generating the document, sending it for validation, and attaching the returned PDF to the delivery process.
Original PR description
This pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking…
This pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking operations. The main changes include configuration for managing and generating e-Remitos according to Uruguayan fiscal requirements. **Steps to create an e-Remito** 1. Install l10n_uy_edi_stock 2. Create a new delivery order. 3. Select a value for the field "Type of Operation". This will indicate that we are creating the electronic document, and also add a tab named "UY EDI" with some configurations for the e-Remito. <img width="1231" height="585" alt="image" src="https://github.com/user-attachments/assets/c4c0baa8-8f9b-4453-b0c0-ce1b1503c536" /> <img width="1211" height="565" alt="image" src="https://github.com/user-attachments/assets/c827f787-27ed-4d55-a660-42a6b617e7df" /> The field "Addenda and disclosures" works as in invoices, the user will be able to select the addenda to add to the e-Remito report. The field "EDI Reference" is used to indicate that the e-Remito is a correction of another, so it will suggest previous e-Remitos made for the same partner, and it will add "Correction of e-Rem XXX" on the addenda. 4. Validate the delivery order and click on "Create Delivery Guide" button. This will send the document to DGI for validation and add the PDF returned by Uruware. <img width="1705" height="618" alt="image" src="https://github.com/user-attachments/assets/8bb36b08-ab08-4240-b3bb-f593a7f2a462" /> Odoo Task 1334 Adhoc Task 53147
Enhancements to existing features
The tax tags used for Belgian reporting now include Belgium as their country. This makes them easier to organize and helps reuse them in other situations where country-specific grouping is needed.
Original PR description
Account tags for 281.50 are specific to Belgium. With this PR, the country is added to those tags, allowing easier group by and enabling their use in other cases as well. task-5236632 Forward-Port-Of: odoo/enterprise#98759
When creating a new company bank account, Odoo now preserves the expected account digit length. This prevents newly generated account numbers from becoming one digit too long, which helps keep numbering consistent and easier to read.
Original PR description
**Description of the issue/feature this PR addresses:** When user creates a new company bank account the new account created has not expected lenght when last digits are more than 1 **Current behavior before PR:** account digits = 6 last bank account = **572009** create new bank account = **5720010** **Desired behavior after PR is merged:** account digits = 6 last bank account = **572009** create new bank account = **572010** cc @Tecnativa --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199587
Stock availability checks are now much faster when a picking contains many linked incoming and outgoing moves. The update reduces unnecessary looping, which lowers waiting time for users and improves responsiveness on large operations.
Original PR description
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings…
Before this commit, computing `product_availability` and `product_availability_state` required calling the `get_report_lines` method from the `stock.forecasted_product_product` model. In pickings containing moves linked to many incoming and outgoing moves, the `reconcile_out_with_ins` function caused performance issues. The reconciliation logic worked as follows: 1. For each `out_move`, attempt to match it with an `in_move` if the `in_move` references the `out_move` in its `move_dests`. 2. If the demand of the `out_move` is not fully satisfied, add it to `unreconciled_outs`. 3. Loop over `unreconciled_outs` (after attempting to reconcile them using the initial prodcedure) to reconcile against the remaining `in_moves`. The performance bottleneck was that even when an `in_move` directly referenced an `out_move`, the code would unnecessarily loop over **all** `in_moves` to filter out the `in_moves` that has the `out_move` in its `move_dest`. --- To improve performance, an **inverse mapping** from `out_move` IDs to their corresponding `in_moves` is introduced. - Reconciliation now starts by iterating only over the relevant `in_moves`. - If the demand is still unmet, the algorithm attempts reconciliation against the remaining `in_moves`. - This reduces the time complexity to **O(N + M)**, since `in_moves` with zero quantities are removed and never revisited. **Implementation details:** - An `OrderedSet` is used for the inverse mapping to preserve the original query order. - Benefits of `OrderedSet`: - **O(1)** removal (assuming no collisions) - Maintains insertion order, ensuring the same order as the query result. --- | Metric | Before PR | After PR | |---------------|-----------|----------| | Execution Time| ~90 sec | ~10 sec | The benchmark above is done on a `stock.picking` record that queried in the `_get_report_lines` method **5331** `out_moves` and **8922** `in_moves`. opw-4951469 Forward-Port-Of: odoo/odoo#224002
Resolved issues and error corrections
This update switches the Colombian exchange rate service to the country’s new central bank API. It restores and simplifies the automatic currency rate update so businesses can keep exchange rates current without interruption.
Original PR description
The previous SOAP API was decommissioned. A new API was provided that doesn't need SOAP anymore and is a bit simpler [1]. [1] https://suameca.banrep.gov.co/estadisticas-economicas/webService opw-4860262
This update corrects a rounding issue in BACS batch exports so payment amounts are written accurately in pence. It prevents small floating-point errors from causing batches to show the wrong amount in the payment file.
Original PR description
**Issue description:** When creating a BACS batch payment that contains a payment with an amount that can't be represented well in float (like 645.30), the generated BACS batch file will have a wrong amount (due to float precision) as the amount is represented in pence. **Steps to reproduce:** 1. Create a BACS vendor payment with amount = 645.30 2. Add this payment to a BACS batch payment. 3. Confirm the batch to generate the export file. In the file you will notice that the amount in the payment line is 64529 pence instead of 64530. opw-5159413 Forward-Port-Of: odoo/enterprise#99180
When account chart templates are reloaded, translations are now updated consistently across all available languages. This avoids situations where some language versions were left outdated while English was refreshed, helping keep localized account labels aligned.
Original PR description
Before this patch: - English terms were always updated when reloading account chart templates. - Other languages were only updated if the corresponding translation was missing. After this patch: - All languages are consistently updated when reloading account chart templates. - Languages where there is no translation remain unaffected. https://www.loom.com/share/1d9367f2b25f42b7b07dc01743f7e008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12331 OPW-5237476
The system now correctly ignores the Raspberry Pi 5’s built-in serial port, which was being shown by mistake on newer Raspberry Pi OS versions. This prevents an internal device from appearing as if it were an available serial connection, reducing confusion and setup errors.
Original PR description
The serial interface previously included a filter to not include the built-in serial port on the Pi 5, however this filter is now broken in Raspberry Pi OS Trixie. To ensure the filter works in all versions, we now explicitly look for the device `/dev/ttyAMA10` and ignore it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235074
This change corrects how payroll-related payments choose the recipient bank account. It ensures payments are sent to the bank account specified by the vendor or partner, instead of always defaulting to the employee’s bank account, which avoids payment errors and misdirected transfers.
Original PR description
## Tests ### test_bank_account_partner_payment_payslip Adding 'test_bank_account_partner_payment_payslip' test to check that the payment generated for Professionnal Tax is made to the correct bank account (before this fix, the selected account was always the employee bank account, whatever the vendor specified in the payment). ### test_sepa_payslip_partner_bank_id Adding 'test_sepa_payslip_partner_bank_id' test to check that the "partner_bank_id" is set after account_register_payment wizard has been initialized and that the action_create_payments (action launched when the user clicks on "Create Payments" button of the account_register_payment wizard) doesn't raise any error. [Task#4979220](https://www.odoo.com/odoo/all-tasks/4979220) [Community#229506](https://github.com/odoo/odoo/pull/229506)
This change ensures payslip payments use the correct recipient bank account instead of always defaulting to the employee’s bank account. It also prevents an error when users click Pay from the payroll payment screen, so salary-related payments can be created and processed reliably.
Original PR description
## Issues ### Issue 1: incorrect payslip payment bank account When you perform the "pay" action of a payslip, the bank account registered within the resulting payments is always the bank account of the employee, even though some payments should be made to a different bank account (taxes). ### Issue 2: error when clicking on "Pay" in hr_payslip When a payment is created using the "Pay" button defined in the `enterprise/hr_payroll_account/views/hr_payslip_views.xml` (action `action_register_payment`), an error occurs because of the `partner_bank_id` property not being set even when the `partner_id` is set. The `partner_bank_id` returned by the `_get_line_batch_key` method of the `account_payment_register` is not set correctly when calling the method `action_register_payment` from the `hr_payslip`. ## PR Purpose Fix the issues [Task#4979220](https://www.odoo.com/odoo/all-tasks/4979220) [Enterprise#96019](https://github.com/odoo/enterprise/pull/96019)
Products that give access to a course will now be visible in the website shop again. This fixes a visibility issue that prevented customers from finding and buying course-related products, even when searching by name.
Original PR description
Currently, course-related products do not appear in the e-commerce. ### Steps to Reproduce 1. Create a product with type 'Service'. 2. Configure the product to grant access to a course. 3. Publish the product 4. Navigate to the shop as a public user. The course product does not appear, even if you search its exact name ### Cause Since fbbd0aae7b8a6bd9ef35566e712772e3170e31bd, a product's type needs to be explicitly defined as "saleable" for it to be visible on the website shop. The 'course' service tracking type was not included in this list of saleable types. opw-4995639
The OEE value shown on workcenter screens now matches the detailed report users see when they open it. This fixes a rounding issue that could cause small but confusing differences between the summary value and the report, improving trust in production metrics.
Original PR description
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed…
**Current behavior:** The form view for a workcenter has an OEE smart button which can display a different value from the real OEE displayed by the `mrp_workcenter_productivity_report_oee` displayed when actually clicking the button and looking at the report. **Expected behavior:** Same values **Steps to reproduce:** 1. Make a workcenter and a BoM with an operation performed at the workcenter 2. Use the BoM in an MO such that there is some un-productive time (e.g., recorded production duration takes longer than expected duration) * example: 0:20 expected, 1:01 actual 3. Go to the workcenter list view -> click on the created workcenter -> look at OEE smart button display value -> click on it to see report -> report values are different **Cause of the issue:** the `oee` field on the workcenter is computed with rounded intermediary `blocked_time` and `productive_time` values, the actual report uses the raw values. **Fix:** Don't use the rounded intermediary values in computing `oee`. Post-this-diff, we actually do one less `_read_group` (along with computing a more accurate field value). opw-4795463 Forward-Port-Of: odoo/odoo#218310
When adding an element to a report, the editor now keeps the cursor and selection in the right place. This makes it easier for users to continue typing or interacting with the report immediately after an insert, without unexpected focus changes.
Original PR description
On a new report, add a X2Many table in a new Report. In many cases there will be some issues with the selection as, when inserting the Element via the command of the report Editor we explicitly focus the editable of the html_editor. We need the document inside the iframe to get the focus, because our flow implied to click on some popover bound to the main window. But focusing the editable element changed the selection. So, instead, we focus the iframe's inner window, and the selection stays at the right place, and the user can immediately interact with it (by continuing typing after the insertion) task-5159482
This fix allows users to generate a debit note from an existing credit note in the Argentine localization. It removes an error that previously blocked this correction flow, making it easier to properly reverse and adjust mistaken documents.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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#225501
This update fixes several issues in the Uruguay vendor bill synchronization flow. It now processes all invoice records from uploaded XML files, keeps better track of manually uploaded versus automatically created documents, and improves reliability with batched background processing.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355
This update corrects how fixed local taxes are written into Mexican CFDI XML files. It prevents the tax amount from being multiplied by 100, ensuring invoices and payments show the right local tax values.
Original PR description
Steps to reproduce: 1. With an MX Company setup configure a new tax as follows - Tax Computation: Fixed - SAT Tax Type: Local - Factor Type: Cuota - Amount: 5 2. Create a customer invoice with the tax 3. Generate CFDI Issue: In the XML the ImpuestosLocales node contains `<implocal:TrasladosLocales ImpLocTrasladado="VAT 0%" Importe="20.00" TasadeTraslado="500.00"/>` The tax fixed amount was multiplied by 100 This occurs because we don't check if the tax is fixed when normalizing the amount opw-5132807
This update refreshes the spreadsheet component to the latest version and includes a few bug fixes behind the scenes. It helps prevent crashes in specific chart actions and improves handling of sheet names with special characters, making spreadsheet use smoother and more reliable.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d1efb0b98 [REL] 18.0.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d1efb0b98 [REL] 18.0.48 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3c69b7271 [FIX] range: invalid sheet name with special character [Task: 5125762](https://www.odoo.com/odoo/2328/tasks/5125762) https://github.com/odoo/o-spreadsheet/commit/c8a3d2bb8 [FIX] charts: crash when converting empty chart to scorecard/gauge [Task: 5181741](https://www.odoo.com/odoo/2328/tasks/5181741) https://github.com/odoo/o-spreadsheet/commit/e067ec76f [FIX] Package: update owl to 2.8.1 [](https://www.odoo.com/odoo/2328/tasks/) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> 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: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@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> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This change ensures that when a POS order linked to a sales order is refunded from the backend, the invoiced quantity on the related sales order line is updated correctly. It prevents the system from showing an incorrect invoiced status after a refund, which helps keep sales and invoicing records accurate.
Original PR description
When doing a refund of a POS order linked to a SO in the backend, the qty_invoiced on the SO line is not updated correctly. Steps to reproduce: ------------------- * Create a SO with 1 quantity of any product * Settle the SO in the PoS * Refund the PoS order from the backend not from the PoS interface * Check the qty_invoiced on the SO line > Observation: The qty_invoiced is still 1 Why the fix: ------------ The method _compute_qty_invoiced was not triggered when the refunding order was paid. So we need to add a new dependency on the function. Note: ----------- In the test we need to flush all before doing the payment of the refund, because if we do not do it, the _compute_qty_invoiced method would be called during the payment. But that is not the case outside of the test. This is just to ensure that the test fails correctly without the fix. opw-4991405
This change makes sure timesheet entries are properly tied to credit notes, not only regular invoices. It prevents already-invoiced time from remaining editable, which avoids billing inconsistencies and protects the accuracy of customer invoicing.
Original PR description
To reproduce: ============= - create service product based on timesheet that creates project/task - create sale order with this product with qty of 10h and confirm it - take advance payment on this sale order of 50% (downpatment invoice) - record 4h of timesheet entries on the task - create regular invoice which will be a credit note as we owe the customer 1h - check that the credit note is linked to the timesheet and we can modify the timesheet which is not correct for an invoiced timesheet Problem: ======== when creating invoices and linking them to timesheet we only take into account the regular invoices, not the credit notes. Solution: ========= we should also take into account credit notes when linking timesheet entries opw-[4850089](https://www.odoo.com/web#id=4850089&view_type=form&model=project.task) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents the footer in the Wave document layout from shrinking and overlapping the document content when viewed on mobile. It improves readability for invoices and other portal documents with multi-line footers.
Original PR description
In the Wave layout, a multi-line footer overlaps document information when the portal view is opened from a mobile interface. Steps to reproduce: - Open Settings > General settings > Configure Document Layout - Select Wave layout and add a multi-line footer - Open an invoice, go to portal preview, switch to mobile view Issue: The footer overlaps invoice information. This occurs because the boundaries of the SVG drawing are not well defined and it will unexpectedly shrink. opw-5023032
This update corrects how the system reads a configuration setting used during journal setup for ISO 20022 payments. It helps ensure the right settings are available when needed, reducing the chance of errors in payment configuration.
This fix ensures stock valuation entries are created with the right amounts when a purchase order is paid in a different currency. It helps keep inventory and accounting values accurate and avoids mismatches in financial records.
Original PR description
…er currency fix fait, check stable puis test et commit msg
This fix ensures that a CRM lead’s stage is updated when its sales team changes, especially when a user belongs to multiple teams. It prevents leads from staying in a stage that no longer matches the selected team, helping teams keep pipeline information accurate.
Original PR description
**Steps to reproduce:** - Install CRM and set the Leads configuration setting - Go to CRM > Configuration > Sales Teams - Create two Sales Teams - Go to CRM > Configuration > Stages - Create multiple stages specific to each team - Make the current user belong to both teams - Go to CRM > Leads - Create a new lead (stage is assigned here) - Change its Sales Team - Lead stage is not updated according to the team **Issue:** The `stage_id` of `crm.lead` is never updated after it is set. This means that changing the related team will not modify the possible stages of the lead (even if it should not be available to the current team). **Fix:** Check if the team of the lead is the same as the one of its current stage during `_compute_stage_id`. opw-4901009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes drag-and-drop test steps finish cleanly before a test ends. It helps prevent flaky test results and makes the test suite more reliable.
Original PR description
Since drag sequences are automatically canceled at the end of tests, 'cancel' or 'drop' calls should be properly awaited before the end of a test. This commit ensures that these actions are properly finished before a test ends. Community: https://github.com/odoo/odoo/pull/235359
This change improves automated web tests by ensuring unfinished drag actions are properly canceled at the end of each test. It prevents stray asynchronous errors from appearing after tests complete, making test results more reliable and easier to trust.
Original PR description
Before this commit, when initiating an unfinished drag sequence (i.e. calling `drag` without `drop` or `cancel`), the drag sequence was ended by destroying the component, which could throw asynchronous errors after the test finished. One possible fix would be to wait for these errors upon ending a test, but this process is handled by Owl and through a possible chain of promises, which would have to be accounted for by an arbitrary amount of 'animationFrame' or 'advanceTime' calls. Instead, the `contains...drag` and `contains...dragAndDrop` now handle a single drag sequence at a time, with a systematic cleanup after each test in case a drag sequence has been left pending. In such cases, the sequence is canceled. Enterprise: https://github.com/odoo/enterprise/pull/99369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an occasional test failure in the web interface by waiting for the error dialog to actually appear before checking for it. It makes automated testing more reliable and helps prevent flaky build results.
Original PR description
Before this commit, the test sometimes failed because we didn't wait enough before checking the presence of the error dialog. The `unhandledrejection` event being thrown asynchronously, simply waiting for an animation frame isn't enough. We can only wait for the dialog to be displayed. runbot error~234017 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes interactive tours handle warning steps correctly when going backward. If a previous step is only meant to be skipped, the tour will no longer stop on it or briefly focus the wrong place before moving on. This makes tour navigation more reliable and avoids confusing behavior during guided flows.
Original PR description
Before this commit, the backward wasn't ignoring the warn steps. So, if the backward go to the previous step (warn's one) and the trigger is on the page, the tour interactive put the cursor there. But the step is then ignored and go back the step you came from. Now, the warn's steps are ignored. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change makes several editor tests more reliable by giving each test its own time allowance instead of sharing one across all of them. It helps prevent false failures on slower test servers, improving confidence in the quality of future releases.
Original PR description
Split the test timer between the four tests rather than applying
a single timer over all of them, for when the runbot is slower.
runbot-233975This fix corrects how Pivot view rows are expanded when grouping by an order field. Instead of showing a single generic entry with a count of 1, the view now displays the actual orders underneath the selected row, making reporting more accurate and easier to use.
Original PR description
Steps to reproduce ------------------ 1. On a new DB, go to PoS > Reporting > Orders 2. Choose the Pivot view 3. Click on a row, click 'add custom group', choose 'Order' The row should expand showing the orders belonging to it, but instead, only one entry is added, and it's not showing the order name, just "1". What's happening ---------------- We are grouping by 'order_id', but since 'order_id:count_distinct' is in the `measureSpecs`, we're counting the number of orders instead of returning their IDs. In other words, since we are grouping by a unique field 'order_id', and also counting the number of row in such a group, we always get 1. Solution -------- If the goupby field exists in `measureSpecs`, return it as is without aggregating on it. opw-5187181
This fix ensures the system always sends the right reconnection signals when a web connection drops unexpectedly, even if the closing process was interrupted. It improves reliability of live connection handling and resolves an intermittent test failure seen in automated builds.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix lets vendor bills and invoices with deferred amounts be reset to draft multiple times, even when audit trail protections are enabled. It prevents users from getting blocked by already-cancelled deferred entries, making it easier to correct and reprocess these documents.
Original PR description
Resetting a vendor bill or invoice with deferred amounts will unlink or reset all existing deferred entries. If the audit trail is enabled, some of these entries must be cancelled instead. [AccountMove.button_draft()](https://github.com/odoo/enterprise/blob/a3f461040cb3443fbcb190c28fddae7044bbd1e7/account_accountant/models/account_move.py#L80-L88) If a protected entry is already cancelled, `AccountMove._unlink_or_reverse()` will still attempt to cancel it. This prevents entries from being Reset to Draft more than once. The current commit removes this restriction. opw-5187737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235223
This update makes sure kanban views keep a safe record limit when users remove grouping and then switch back. It prevents the web interface from trying to load too many records at once, which could slow down or even crash the page.
Original PR description
Steps to reproduce ================== - Add a group by in the kanban product view - Switch to the list view - Remove the group by - Switch back to the kanban view -> No limit is applied, and the webclient can crash if too many records are returned. Cause of the issue ================== The groupsLimit is set as MAX_SAFE_INTEGER in the kanban view https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/views/kanban/kanban_controller.js#L168 Which is then reused as the limit https://github.com/odoo/odoo/blob/df959e05ac9cf3136d1724bc80b7597a70932225/addons/web/static/src/model/relational_model/relational_model.js#L368 Solution ======== There is already a code path to reset the limit when switching from grouped to ungrouped, but is wasn't called on the first load (when this.root isn't set yet) opw-5167769 Forward-Port-Of: odoo/odoo#235232
Fixed an issue where scanning the packaging of a kit product variant could fail during barcode operations. The barcode app now correctly recognizes the kit variant tied to that packaging, preventing scan errors and keeping receipt processing smooth.
Original PR description
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product KIT with 2 variants (for instance add the color attribute with the "white" and "black") - Crete a kit bom for…
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product KIT with 2 variants (for instance add the color attribute with the "white" and "black") - Crete a kit bom for this product: 1 x COMP - Go to Inventory > Configuration > Products > Product Packagings - Create a new packaging for KIT (white) with barcode XXX - Create a receipt for 1 unit of KIT (white) - Go to the barcode app > scan your receipt - Scan XXX #### > Error: Record product.product doesn't exist in the cache, it should return by the server ### Cause of the issue: Since commit c3fdc6e07fe7704340691fcc1bd7ed3cfb19abaf, the packaging related to KIT (white) is added to the barcode cache by the `_get_stock_barcode_data` (which was necessary to solve the related issue): https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode_mrp/models/stock_picking.py#L9-L18 However, the `KIT (white)` product itself is not be present in the cache as only products present in move lines are added the barcode cache when opening the operation in barcode: https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/models/stock_picking.py#L93-L95 This causes the issue as the package scans find the packaging in the barcode cache but can not recover its related product from it aswell: https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L988-L990 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/models/barcode_model.js#L1251-L1252 https://github.com/odoo/enterprise/blob/2d854711239775668d01604733d546dd40fe9f5f/stock_barcode/static/src/lazy_barcode_cache.js#L75-L80 opw-4852875 Forward-Port-Of: odoo/enterprise#98057
This update fixes how the self-order IoT feature reads image version numbers. It ensures newer image version formats are recognized correctly, preventing issues when loading or updating images.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting.
Follow-up reminders now correctly send any files and dynamic reports configured in the email template. This ensures customers receive the full reminder package as intended, improving consistency and reducing manual follow-up work.
Original PR description
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the…
### Issue: We can add attachments and dynamic report to the email templates, but they are not sent with follow-ups. ### Steps to reproduce: - Go to the "Payment reminder" email template - Under the page "Content", add an attachment by clicking the "Attachments" button - Under the page "Settings", add a dynamic report - Create an overdue invoice for a partner - Go on the form view of the partner, "Accounting" page - Click "Send", make sure the template used is the one with the attachments - Send - The attachments on the template and the dynamic report are not sent ### Cause: The mail template to send the follow-ups is only used to prefill the wizard. ### Solution: Add the template in `_get_wizard_options()` to add the template in the option and later use it to add/generate its attachments. This commit also refactors how the attachments are computed: The previous code was adding the invoices PDFs then removing them. The whole process was confusing. Now `options['attachment_ids']` is appended in `_get_followup_attachments()` with the desired attachments depending on the options. opw-5147736
This change corrects how imported supplier refunds are handled when they match a purchase order. It prevents the document type from being altered after the match, so refunds stay recorded correctly and accounting data remains accurate.
Original PR description
The `move_type` is changed after PO match. This PR fixes the case of import a refund that matches a PO so the `move_type` is not changed after matching. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr