Daily updates from Odoo
Friday, March 27, 2026
30 changes · 18.0
New functionality added to Odoo
This update integrates Viettel SInvoice, enabling Point of Sale (PoS) systems to automatically generate and attach e-invoices compliant with Vietnamese regulations. The changes improve the PoS system's ability to meet local tax requirements and streamline the invoicing process for Vietnamese businesses. A key technical update involves extracting invoice file retrieval logic for reusability and improved accuracy.
Original PR description
Add Viettel SInvoice integration with the Point of Sale module to support PoS e-invoicing for the Vietnamese market. task-4844619
Enhancements to existing features
This update incorporates changes to India's tax regulations (IT Act 2025) regarding TDS and TCS. It adds new tax sections and calculations aligned with the updated legislation, ensuring accurate reporting and compliance. Existing tax configurations have been deactivated to reflect the new rules.
Original PR description
The Income Tax Bill 2025 introduces TDS and TCS provisions in a more structured way compared to the existing Income-tax Act 1961, with the addition of new sections and taxes. This commit adds new sections and corresponding taxes for sections 392, 393, and 394, along with their respective reports. It also introduces new TDS and TCS tax groups for these taxes to differentiate them from the existing ones. The old taxes are deactivated as they are no longer applicable. task-6035844
Resolved issues and error corrections
This update fixes an issue where barcode scans didn't correctly apply putaway rules, resulting in incorrect destination locations for new stock moves. The fix ensures that barcode-created moves now automatically use the designated shelf location as defined in the putaway rules, improving inventory accuracy.
Original PR description
**Steps to reproduce:** * Install the `stock` module. * Go to Inventory → Configuration → Settings and enable Storage Locations(warehouse). * Create a new tracked product: * Enable Track Inventory by…
**Steps to reproduce:**
* Install the `stock` module.
* Go to Inventory → Configuration → Settings and enable Storage
Locations(warehouse).
* Create a new tracked product:
* Enable Track Inventory by Lots.
* Assign a Barcode to the product.
* Go to Inventory → Configuration → Putaway Rules and create a rule:
* When Product arrives in:`WH/Stock`
* Store to: `WH/Stock/Shelf 1`
* Go to Inventory → Configuration → Operations Types → Internal
Transfers and enable Create New under Lots/Serial Numbers.
* Open the Barcode application.
* Navigate to Operations → Internal Transfers and create a New
transfer.
* Scan the product barcode.
* Scan lot lot1.
* Scan lot lot2.
**Issue:**
The barcode flow sets a wrong destination location on the generated move lines.
Current:
- `WH/Stock`
Expected:
- `WH/Stock/Shelf 1`
The destination should follow the putaway rule, but barcode-created lines
keep the raw operation destination instead of the putaway-resolved sublocation.
**Cause:**
The issue comes from the barcode new-line creation flow.
The scan starts in `BarcodeModel._processBarcode()`
When no matching line is found, `_processBarcode()` prepares the scanned values
with `_convertDataToFieldsParams()` then calls `createNewLine()`
`createNewLine()` is only a wrapper and directly forwards the
call to `_createNewLine()`
So the flow is:
`_processBarcode()` -> `_convertDataToFieldsParams()` then `createNewLine()` ->
`_createNewLine()`
Then the real issue comes in `_createNewLine()`
where the new line is created with:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L798-L802
The data used by `createNewLine()` comes from `_convertDataToFieldsParams()` in
There, `location_dest_id` is only set if the user explicitly scans a
destination location, at and In this flow no destination location is scanned
manually,
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_picking_model.js#L1170-L1173
so `fieldsParams` does not contain
`location_dest_id`.
Because of that, `_createNewLine()` falls back to `_getNewLineDefaultValues()`
in which sets:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L877
`_defaultDestLocation()` itself simply returns the picking destination location
So the issue is that the barcode model has no putaway handling when creating a
new line.
It simply takes the default destination from the picking, and that is
why the move line gets `WH/Stock` instead of the putaway destination
`WH/Stock/Shelf 1`.
**Fix:**
The fix is to handle putaway when a new line is created from the Barcode app.
Since the base barcode model does not handle putaway for new lines,
So add that logic in `BarcodePickingModel._createNewLine()`.
The new flow is:
- if a destination location was explicitly provided in `fieldsParams`,
keep it as is
- if a selected line already exists for the same product and already has
the correct destination, reuse that selected line destination
- otherwise, make one RPC call to get the putaway-resolved destination
for the new line
This RPC returns the correct destination according to the putaway rule,
and that value is assigned to the new line instead of keeping
the normal picking destination.
With this fix, barcode-created lines no longer fallback to `WH/Stock`.
They now use the correct putaway destination `WH/Stock/Shelf 1`.
---
opw-5220141This update fixes an issue where failing quality checks in subcontracting production orders led to incorrect quantity updates, causing inconsistencies in recorded products. The change ensures that quantities are correctly reduced from productions linked to the inspected lot, preventing unintended impacts on recorded products. This improves the accuracy of inventory tracking within subcontracting processes.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue** In subcontracting, a failing quality check could lead to inconsistent quantities. **Steps to reproduce** - Create two tracked products…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.
**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
- Operation type: Receipts
- Control per Quantity
- Create a PO for the final product:
- With a quantity of 3
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product
-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available
**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94
When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471
This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320
As a result, the reduction could be applied to a production unrelated to the inspected lot.
**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.
opw-5427873A recent update to the approval report caused partner names exceeding 63 characters to overflow, making the report unreadable. This fix adds a column limit to the partner field in the report, ensuring all data is displayed correctly and preventing visual errors. This improves the report's usability and data accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752
This update fixes a warning displayed in the tax report when vendor bills have expense lines with different vehicle assignments. The fix allows for accurate reporting even when some expense lines are associated with a vehicle and others are not, ensuring consistent tax calculations. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645
This update corrects a calculation error in the bank reconciliation widget's tax handling. Previously, RC taxes were incorrectly calculated as 'price included' leading to inaccurate tax amounts. This fix ensures RC taxes are calculated correctly, resulting in the expected tax amount of $25.00 for transactions.
Original PR description
Currently, when we add a tax in the manual operations tab of the bank reconciliation widget, tax computation will be forced as price included. The computation reverts to price excluded when altering the amount. Steps to reproduce: - Create a Statement line of 1000$ - In the Writeoff add 2.5% RC tax - Check created tax lines Issue: Adding a 2.5% RC tax gives 24.39 instead of 25.00 opw-5039386
This update resolves a bug that occurred when creating contracts with working schedules that had zero hours. The issue caused a calculation error (division by zero) during wage computation. This fix ensures accurate wage calculations for employees with zero-hour schedules, preventing the error and improving payroll reliability.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930
This update adds a 200% overtime wage type within the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). This change ensures accurate reporting of overtime compensation to tax authorities in Switzerland, complying with local regulations. It corrects a previous limitation and improves payroll accuracy for Swiss businesses using this module.
Original PR description
Forward-Port-Of: odoo/enterprise#110796
This update resolves an issue preventing the export of Profit & Loss reports with footnotes enabled for the l10n_lu_reports module. The fix corrects a dependency on an outdated model, ensuring proper XML generation and report functionality. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#107765
This update resolves an issue where QR-IBANs were incorrectly processed for creditor accounts. The fix ensures QR-IBANs are handled according to documentation, aligning with best practices for payment processing and preventing potential bank rejection errors. This improves the reliability of our payment integrations.
Original PR description
https://github.com/odoo/enterprise/pull/112273 introduced a bug, where qr-iban are put inside Othr node instead of IBAN node for the Creditor account. According to documentation, for the debtor account, you should not use a qr-iban, and if you do, it should be put inside the Othr node (even if in this case, the transfer will probably be refused by the bank).
This pull request removes a context dependency within the quality control module. A previous change needed to be reverted due to issues on the OC side. This change ensures the quality control functionality operates consistently without relying on specific contextual data, improving stability.
Original PR description
Commit [1] must be reverted, cf commit OC side [1] 690293e3daae7ac393e93df1976c2c8364dbe0e0
This update resolves a problem where the Settings app stopped working after uninstalling the `hr_recruitment_extract` module. The fix ensures that if one module is removed, its dependency on another module is also handled, preventing errors and maintaining app functionality. This improves stability and user experience.
Original PR description
Consider the following scenario: 1. User installs the `hr_recruitment_integration_monster` module. 2. User can access the Settings app just fine. 3. User uninstalls the `hr_recruitment_extract` module. 4. User can no longer access the Settings app due to a view rendering error. This is because a view in the `hr_recruitment_integration_monster` module depends explicitly on an XPath introduced by the `hr_recruitment_extract` module. When the latter is uninstalled, the view in the former module becomes invalid, causing a rendering error in the Settings app. This commit makes the module dependency explicit in the manifest so that if the `hr_recruitment_extract` module is uninstalled, the `hr_recruitment_integration_monster` module will also be uninstalled.
This update resolves an issue where the Master Production Schedule (MPS) wasn't properly considering safety stock levels for indirect demand. The change ensures that demand forecasts accurately reflect the need to buffer against potential supply disruptions, improving production planning accuracy. This primarily impacts how the system calculates and schedules production for components.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838
This update fixes an issue where Odoo's translation caching wasn't working correctly when related translated fields were updated. Now, when a translated field changes, dependent calculations using that field's translation will continue to use the existing cached translation, improving performance and ensuring accurate translations across different languages. This enhances the user experience by reducing unnecessary processing.
Original PR description
when related translated field (field_x) is changed when onchange, if another computed fields which depends on the field_x is recomputed but using another language value of the field_x. The orm should keep the existing translations in the cache but not drop them. 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#256111
This update streamlines the testing process for the Live Chat module by pre-generating a key asset bundle. Previously, this bundle was rebuilt repeatedly during tests, causing performance slowdowns. This change significantly reduces test execution time and improves overall system stability.
Original PR description
This commit sets the `im_livechat.assets_embed_external` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +280 times with a db "all"). Forward-Port-Of: odoo/odoo#255847
This update fixes an issue where failing quality checks in subcontracting production orders incorrectly reduced quantities, leading to inconsistencies. The change ensures that quantities are accurately deducted from the correct production orders when a quality failure occurs, resolving a discrepancy in recorded product quantities.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue** In subcontracting, a failing quality check could lead to inconsistent quantities. **Steps to reproduce** - Create two tracked products…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.
**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
- Operation type: Receipts
- Control per Quantity
- Create a PO for the final product:
- With a quantity of 3
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product
-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available
**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94
When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471
This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320
As a result, the reduction could be applied to a production unrelated to the inspected lot.
**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.
opw-5427873This update resolves an issue where the HTML editor would unexpectedly scroll to the top when the command palette was closed. The fix utilizes a temporary workaround to maintain the user's selection and avoids impacting the command palette or ui_service. This improves the overall editing experience.
Original PR description
Before this commit: the editable area scrolls to the top when the command palette is closed by clicking the gray zone After this commit: we override the focus function of the editable and use focusEditable instead, which keeps the selection. Note it's a succession fix of https://github.com/odoo/odoo/pull/250624 and both of them are a workaround without touching the ui_service and command palette. Also added super.destroy() in the previous fix till 18.4. task-6034339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that when creating new analytic items through the gross margin smart button, the correct analytic account is automatically selected. Previously, a new record didn't link to an account, requiring manual setup. This change streamlines the process and improves data accuracy for analytic reporting.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#255726
This update removes the ability to automatically retain zero-value account move lines, which were often created with incomplete data. This improves data cleanliness and reduces potential reporting issues within the accounting module. The change allows users to manually remove these lines when appropriate.
Original PR description
-added some conditions to allow the user to remove some zero move lines as they may have been created and do not have good information. task-4590580 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 update resolves an issue where the text editor cursor wasn't updating correctly in iOS Safari when the editor was collapsed (e.g., minimized). By adjusting where the cursor is positioned, the text editor now functions as expected, ensuring accurate input and formatting in this common scenario. This improves the user experience for iOS Safari users.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several issues within the odoo spreadsheet library, ensuring smoother spreadsheet functionality and improved performance. The changes address problems with Excel exports and cell rendering, enhancing the overall user experience. This is a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/046ebe02e7 [REL] 18.0.61 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/046ebe02e7 [REL] 18.0.61 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d2bcfec2ad [FIX] grid_renderer_store: keep wrapping width with explicit align [Task: 6032407](https://www.odoo.com/odoo/2328/tasks/6032407) https://github.com/odoo/o-spreadsheet/commit/bb23b58c4f [FIX] config: fix release flow [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/cdc17289d2 [FIX] SheetView: dirtify sheet viewport at UPDATE_CELL [Task: 5953775](https://www.odoo.com/odoo/2328/tasks/5953775) https://github.com/odoo/o-spreadsheet/commit/c98ebc55ee [FIX] xlsx: do not export dynamic tables to excel [Task: 5214240](https://www.odoo.com/odoo/2328/tasks/5214240) 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 update fixes issues with how Odoo captures Chrome logs during shutdown, ensuring critical errors are recorded. The changes also enhance the stability of the shutdown process by addressing log buffering problems and adding safeguards to handle Chrome termination issues.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256123 Forward-Port-Of: odoo/odoo#256061
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The team has switched to a modern URL API for encoding, ensuring accurate URL rendering in the user interface. This improves email functionality and user experience.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689
This update resolves an issue where the Point of Sale app on iOS/Safari experienced crashes due to IndexedDB connection interruptions. Specifically, the app now handles situations where the database connection is lost or the app returns from the background, preventing errors and improving overall stability for iOS users. This ensures a smoother Point of Sale experience.
Original PR description
On iOS/Safari, the WebKit IDB server process can be killed by the OS (e.g. due to memory pressure when the app is backgrounded), resulting in an UnknownError: "Connection to Indexed Database server lost". Additionally, returning from background can leave the connection in an InvalidStateError "closing" state while this.db remains non-null. opw-5121896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that was causing instability in our VoIP testing environment. Specifically, the system was leaking memory due to unremoved event listeners, which impacted the performance of related components. By cleaning up these listeners after each test, we've improved the reliability of our VoIP tests and overall system stability.
This update resolves a technical issue related to the cbor2 library, a component used in Odoo. The previous version relied on an outdated build system, which was removed in a recent update to the Python packaging tools. The change ensures Odoo continues to function smoothly and reliably.
Original PR description
cbor2 5.4.2 build system depends on pkg_resources which has been removed in setuptools 82. cbor2 5.4.3 improves their build system and has otherwise no functional changes. fixes #248315 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when users attempted to create scrap orders without a designated scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, resulting in a traceback. This change ensures smoother operation for scrap order creation.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses an issue where picking actions within the MRP and stock modules could trigger unintended consequences. The changes aim to stabilize these processes and avoid disruptions to inventory management. This resolves several related operational problems (opw-6069780, opw-6065341, etc.)
Original PR description
Commit [1] impacts some other flows (like on a picking) [1] 63e44737fe469ab56b8e8e96c1ad47205ead1094 opw-6069780 opw-6065341 opw-6071663 opw-6073396 opw-6065189 opw-6070129 opw-...
This update corrects a bug where modifying a recurring event's start time would incorrectly recreate Outlook events, leading to duplicate invitations and notifications. The fix ensures Microsoft IDs are preserved, preventing these issues and improving the reliability of meeting synchronization.
Original PR description
When an attendee syncs a recurring event where the first occurrence (base event) was modified by the organizer, `_write_from_microsoft` falsely triggers the destructive recreation path. This happens because `_has_base_event_time_fields_changed` compares the exception's modified time against the seriesMaster's pattern time, detecting a "change" even though the master hasn't changed. This causes: - All non-base events lose their microsoft_id and ms_universal_event_id - The base event gets recreated without Microsoft IDs - A duplicate event is pushed to Outlook on the next odoo2microsoft sync - Spurious "join the meeting now" notifications are sent to attendees Add a `follow_recurrence` guard so that when the base event is an exception (follow_recurrence=False), the non-destructive else branch is taken instead, preserving all Microsoft IDs. Forward-Port-Of: odoo/odoo#254414