Tuesday, May 12, 2026
14 changes · saas-18.4
Resolved issues and error corrections
This update refreshes Odoo's spreadsheet component to the latest 18.4 release and includes fixes to the related release workflow. It helps keep spreadsheet features reliable while improving the internal process used to publish future updates.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/dafe57f32e [REL] 18.4.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/dafe57f32e [REL] 18.4.38 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/dda090e2c9 [FIX] package: husky should run at post install [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f076750e2e [FIX] workflow: fix the tag definition [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5a79ef6313 [FIX] Workflow: fix missing permission to use OpenID Connect [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d2f40770e7 [FIX] workflow: Split the workflow in parallel jobs [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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>
Fixed an issue where sub-tasks could show duplicate status bars after their project was cleared. The task form now stays consistent by keeping the sub-task aligned with its parent project's behavior, reducing confusion for users managing project tasks.
Original PR description
Steps: - Create a task inside any project. - Create a sub-task under that parent task. - Open the sub-task and remove the project (clear the project field). - Look at the status bar at the top of the form view. Issue: - The status bar is displayed twice (both the Project stages and Personal stages - are visible simultaneously). Cause: - When the project field is cleared from a sub-task in the UI, conflicting visibility rules or residual stage data can cause the status bar widget to render twice. Fix: - To resolve this, an `onchange` event is added to the `project_id` field. If the user removes the project from a sub-task, the system now instantly falls back to the parent task's project and sets `display_in_project = False`. This syncs the frontend UI with the intended backend behavior, preventing the interface from entering the broken state and removing the duplicate status bars. task-6033970 Forward-Port-Of: odoo/odoo#255319
This fixes an issue where pressing backspace at the far left edge of a button in the HTML editor could cause an error. It also makes backspace behave as expected in that position, improving editing reliability for users working with buttons in content.
Original PR description
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the…
**Description of the problem** Pressing backspace when the cursor is positioned at the very left edge of a button could trigger a traceback. Additionally, even if the crash did not occur, the backspace behavior would be incorrect, because the cursor would move across a zero-width non-breaking space (Zwnbsp) without deleting the first character to the left. **How to reproduce** In the `html_editor`, create a button. Click on its very left edge, then press backspace. An error is thrown. **Why the problem happens** 1. Traceback when backspace is pressed `LinkPlugin.handleDeleteBackward` assumes that `previousSibling` is an element node, and calls the `matches` method. However, when clicking on the very left edge of a button, the cursor is positioned such that the left sibling (`previousSibling`) is a text node. Text nodes do not implement `.matches()`, leading to the crash. 2. No deletion of the character to the left of the cursor `DeletePlugin.isVisibleChar` handles the edge cases where backspace is pressed while the cursor is positioned to the side of a button, and defines the visibility of Zwnbsp to determine how much is deleted. The padding Zwnbsp to the left of a button are considered as visible, such that the user can delete an empty button without removing also the first character on its left. Anyway, the current code does not actually check if the button is empty, thus it applies to more cases than necessary. Probably this has never been observed before, because it takes a very precise click to the left edge to position the cursor between a button and its left Zwnbsp. **Fix** 1. Prevent the crash in `LinkPlugin` `LinkPlugin.handleDeleteBackward` now ensures that `previousSibling` is an element node before calling `matches`, otherwise it returns. 2. Fix backspace behavior in `DeletePlugin` `deletePlugin.isVisibleChar` now considers as visible only the Zwnbsp positioned to the left of an empty button. This way, if the user clicks on the very left edge of a button (which moves the cursor outside the button, to the left), pressing backspace actually deletes the character on the left. task-6102282 Forward-Port-Of: odoo/odoo#258858
Opening the background video options no longer fails because an unavailable Vimeo preview video was removed. This helps website editors continue configuring snippets without encountering an error.
Original PR description
Steps to reproduce: 1. Drop any snippet. 2. Click on the background video option. 3. Observe Traceback. The Vimeo video with ID `499761556` is no longer available, causing a traceback when opening the background video options. This commit removes the unavailable video from the preview list. task-6088772
Duplicate messages in electronic invoice exchange logs are now removed when similar lines appear multiple times. This makes issue logs easier to read and helps users focus on the actual information that needs attention.
Original PR description
Before this commit, we had repeated logs (n-times if we had similar lines) but this doesn't help too much. To avoid this we decided to remove duplicated messages Task-None --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263779
This fix ensures translation highlighting appears correctly in website tab descriptions, even when the text is displayed as a block. It helps website editors clearly see which tab description content needs translation or review.
Original PR description
Span elements which have a style that causes them to be displayed as "block" do not have the background color given by the translation span (this is a ["known" issue]) To show the translation state on those nodes, this commit uses the resource `force_background_translation_state_selectors` for the following: - `.o_nav_tabs_description`, the description of tabs in `s_tabs_images` Introduction of `force_background_translation_state_selectors`: cbb2eb2edfeecbc21a70c1a3cba81ad0a7ac9c75 ["known" issue]: https://github.com/odoo/odoo/commit/9addf9617830885532c27abb0ad5fa915e9f8f62 task-5892636
Users can now press Ctrl+A after selecting an image with a caption without triggering an error. The editor correctly selects the editable page content instead of the protected image container, improving reliability while editing rich content.
Original PR description
#### Description of the issue this PR addresses: - When an image with caption is selected, it is wrapped in a `<figure>`, making `<figure>` the anchor node - `selectAll` was resolving the container using `[contenteditable]`, which keeps `<figure>` as the container even though it is `contenteditable=false` - This leads to `<figure>` being passed to `getDeepestEditablePosition`, which cannot resolve a valid `nodeLevelAncestor` and returns null, causing a traceback #### Desired behavior after PR is merged: - `selectAll` now targets the nearest `contenteditable=true` ancestor instead of any `[contenteditable]` #### Steps to reproduce: - Add image and enable caption - Select the image - Press Ctrl+A task-6174371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Egyptian electronic invoices now calculate currency rates from the first real product line instead of section, note, or display-only lines. This prevents incorrect exchange rates on invoices that start with non-billable informational lines, improving tax reporting accuracy.
Original PR description
The currency rate was previously computed using the first invoice line, regardless of its type. This caused incorrect rate calculation when the first line was not a product line (e.g., section, note, or display-only lines). This fix filters invoice_line_ids to use the first actual product line when extracting amount_currency and balance, ensuring that the derived rate reflects a valid monetary line. opw-5208724 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#237535
Tasks linked to sales orders once again show remaining hours in the sales order item dropdown. This restores important visibility for users tracking project work against sold services and helps avoid confusion when choosing the right sales order line.
Original PR description
Steps to Reproduce: - Open any project linked with a sales order - Open task and click on Sale Oder Item dropdown. Issue: - You can see that SOL's with time remaining don't show the amount of time left Reason: - In this PR https://github.com/odoo/odoo/pull/193079 a record (view_task_form2_inherit_sale_timesheet) has been removed. - So the context key `with_remaining_hours` required to show remaining time is missing. Fix: - Add the record back which updates context task-6170953
This update corrects a UI issue where the `l10n_co_edi_ubl` field on the Units of Measure form was missing its label, causing confusion for users. The fix ensures the field is clearly labeled, improving form usability and data entry accuracy within the CO Company settings.
Original PR description
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. -…
Currently, the field `l10n_co_edi_ubl` is displayed without a label in the UoM form, confusing users. **Steps to reproduce:** - Install the `l10n_co_edi` module and switch to the CO Company. - Navigate to Invoicing > Settings. - Enable `Units of Measure & Packagings`. - Open `Units & Packagings` and click `New`. **Observation:** The `l10n_co_edi_ubl` field appears between the `Quantity` label and its corresponding field, but its own label is not visible. <img width="1905" height="324" alt="6180769_before" src="https://github.com/user-attachments/assets/f35c345a-f449-46e4-ad15-6981109fca7a" /> **Root Cause:** The inherited view [1] inserts the field `l10n_co_edi_ubl` before `relative_factor` in the base view [2]. In the base view, `relative_factor` is wrapped inside a `<div>` with a shared label (`Quantity`). Since the new field is inserted inside this structure, it inherits the same layout without having its own label, resulting in the label being hidden. **Fix:** This commit updates the view to ensure that the field `l10n_co_edi_ubl` is properly displayed with its own label, avoiding UI confusion and improving form clarity. **After:** <img width="1907" height="376" alt="6180769_after" src="https://github.com/user-attachments/assets/f96470d3-8df2-4ca4-acf8-f6511a49d725" /> [1]: https://github.com/odoo/enterprise/blob/7b0d07bce92fb4b2cb588344fb0f6e3dd5d94f4a/l10n_co_edi/views/product_uom_views.xml#L4-L13 [2]: https://github.com/odoo/odoo/blob/bae4fa4e0dde2d2e2e4fcdbb968f630c080af818/addons/uom/views/uom_uom_views.xml#L15-L34 opw-6180769 Forward-Port-Of: odoo/enterprise#115933
The 'Waiting for Me' filter in the Sign app was previously fetching all documents instead of only those requiring the current user's signature. This update corrects a technical issue caused by an ORM optimization, ensuring the filter functions as intended, displaying only relevant documents for users to sign.
Original PR description
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature. Steps to reproduce: 1) Install…
When applying the 'Waiting for me' filter in the Sign app, all documents are fetched instead of filtering out documents that do not need the current user's signature.
Steps to reproduce:
1) Install sign with demo data
2) Open sign app and remove default filter
3) Add a filter Waiting for me
Observed Behavior:
All the documents are fetched.
Expected Behavior:
Documents should be filtered out to only show those where the current user is a signer.
Root Cause:
Since [commit](https://github.com/odoo/enterprise/pull/76079/changes/8b5048f63f91a38a710b611d17f5cf27fbd0a18a), The `_search_need_my_signature` method returned `NotImplemented` for any operator other than `in` at [1]. While the filter uses `=` at [2]. Following a recent ORM optimization with the mentioned commit, the operators are now standardized as shown
From:
`('need_my_signature', '=', True)]`
To:
`[('need_my_signature', 'in', [True])]`
This means the search method now receives the expected `in` operator. However, the return logic uses a `not in` condition when filtering documents waiting for signature.
As a result, instead of filtering documents, all documents are returned.
[1]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/models/sign_request.py#L107-L108
[2]- https://github.com/odoo/enterprise/blob/012b42c20b48e8e36298875e3291936e68e72375/sign/views/sign_request_views.xml#L177
Fix:
Corrected the return domain logic to fetch the correct documents.
opw-6026935
Forward-Port-Of: odoo/enterprise#113760This update fixes an issue where PDF Manager action names appeared awkwardly due to a styling class. The change removes this class, resulting in cleaner and more professional-looking action names within the PDF Manager interface. This improves the overall user experience.
Original PR description
Previously, pdf_manager actions used class "text-uppercase". Action names looked awkward. In this commit, we remove the class and properly display action names. task-6159317 Forward-Port-Of: odoo/enterprise#116382
This update fixes an issue where Swedish financial data from SIE files was being incorrectly imported due to encoding differences. The import process has been corrected to properly handle the Swedish characters, ensuring accurate data transfer for Swedish companies using the Enterprise system. This resolves a data discrepancy related to account numbers.
Original PR description
Issue: Non-ASCII charatcter from sie file were lost on import. Steps to reproduce: - in a Swedish company - import the SIE4 exemple file from sie website: https://sie.se/wp-content/uploads/2024/01/SIE4-Exempelfil-Sample-file-1.zip Current behavior: - The account 1090 is imported as "vriga imm anl tillg" instead of "Övriga imm anl tillg" Expected behavior: - The account 1090 is imported as "Övriga imm anl tillg" Cause: CP437 uses 8 bits to represent data. Ö is \x99. However, file was imported using either UTF-8 or ISO-8859-1, where Ö is \xC396 and \x99 doesn't link to anything. This commit update the test file as it was save in cp437 but read as UTF-8. opw-6167408 Forward-Port-Of: odoo/enterprise#116722
This update fixes an issue where newly created stock batches were incorrectly named 'New' instead of following the standard 'BATCH/<TYPE>/000NN' naming convention. The fix ensures batches are correctly named, improving data consistency and reporting accuracy within the delivery order process.
Original PR description
Steps to reproduce 1. Open the Barcode app > Operations > Delivery Orders. 2. Switch to the "Batches" tab. 3. Create a new one. Issue The created batch keeps the placeholder name "New" instead of…
Steps to reproduce
1. Open the Barcode app > Operations > Delivery Orders.
2. Switch to the "Batches" tab.
3. Create a new one.
Issue
The created batch keeps the placeholder name "New" instead of being
renamed to `BATCH/<TYPE>/000NN`.
The barcode kanban "New" button calls `open_new_batch_picking`, which
runs `Batch.create({})` while the action context carries
`default_picking_type_id` set by `stock.picking.type._get_action` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock/models/stock_picking.py#L432.
Since `vals` itself doesn't carry `picking_type_id`, the lookup in
`stock.picking.batch.create()` at
https://github.com/odoo/odoo/blob/f768f276171b079a76324d40307db385f558dda6/addons/stock_picking_batch/models/stock_picking_batch.py#L181
returns an empty recordset, so the sequence-based rename branch is
skipped and the name stays at the field default `'New'`. The
subsequent `super().create` then applies the context default, so the
batch is correctly linked to a picking type but with the wrong name.
opw-6168320