Daily updates from Odoo
Friday, July 11, 2025
54 changes · saas-18.4
Resolved issues and error corrections
This update brings the spreadsheet component up to the latest version, fixing several issues with pivot tables, formulas, date handling, row sizing, and dashboard error messages. Users should see more accurate spreadsheet results and faster Excel imports, especially when working with pivot tables and converted files.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/29b6458fe [REL] 18.4.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/29b6458fe [REL] 18.4.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5a5d3e9bc [PERF] pivot: don't invalidate cache needlessly [Task: 4933971](https://www.odoo.com/odoo/2328/tasks/4933971) https://github.com/odoo/o-spreadsheet/commit/d1739334f [FIX] pivot: don't aggregate calculated missing value [Task: 4933818](https://www.odoo.com/odoo/2328/tasks/4933818) https://github.com/odoo/o-spreadsheet/commit/f5289edb6 [FIX] Cells: newline is not a valid date separator [Task: 4910327](https://www.odoo.com/odoo/2328/tasks/4910327) https://github.com/odoo/o-spreadsheet/commit/e72637703 [FIX] error_tooltip: Do not show cause position in dashboard [Task: 4926129](https://www.odoo.com/odoo/2328/tasks/4926129) https://github.com/odoo/o-spreadsheet/commit/be3eeb838 [PERF] import xlsx: avoid reading all cells multiple times during table_conversion [Task: 4699860](https://www.odoo.com/odoo/2328/tasks/4699860) https://github.com/odoo/o-spreadsheet/commit/329c6e342 [FIX] index: export `GridRenderer` in index.ts [Task: 4909027](https://www.odoo.com/odoo/2328/tasks/4909027) https://github.com/odoo/o-spreadsheet/commit/ec1c5cec8 [IMP] config: ignore .DS_Store file from mac os [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/1c805a532 [FIX] header_size: resize row based on link label instead of full link [Task: 4886598](https://www.odoo.com/odoo/2328/tasks/4886598) https://github.com/odoo/o-spreadsheet/commit/7c0f0ea1d [FIX] pivot: allow to group by error [Task: 4886041](https://www.odoo.com/odoo/2328/tasks/4886041) https://github.com/odoo/o-spreadsheet/commit/371f81000 [FIX] demo: fix `clear` action again [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/099402805 [FIX] demo: Fix new `clear` action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/629280f07 [FIX] cell_composer_store: formula inputs violating blocking data validation [Task: 4876691](https://www.odoo.com/odoo/2328/tasks/4876691) https://github.com/odoo/o-spreadsheet/commit/de02b83b8 [FIX] gauge_chart: accept 1x1 matrix formulas in gauge sectionRule [Task: 4876691](https://www.odoo.com/odoo/2328/tasks/4876691) https://github.com/odoo/o-spreadsheet/commit/f39b1cc08 [FIX] filter_evaluation: unwrap 1x1 matrix [Task: 4876691](https://www.odoo.com/odoo/2328/tasks/4876691) https://github.com/odoo/o-spreadsheet/commit/ba968c1dc [FIX] evaluation_data_validation_plugin: unwrap 1x1 matrices [Task: 4876691](https://www.odoo.com/odoo/2328/tasks/4876691) https://github.com/odoo/o-spreadsheet/commit/ef59bdfe4 [FIX] evaluation_conditional_format: unwrap 1x1 matrix results [Task: 4876691](https://www.odoo.com/odoo/2328/tasks/4876691) 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: Mehdi Rachico (mera) <mera@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>
The hardware drivers now check that certificate data received from Odoo is not empty before applying it. This avoids failed web server restarts that could disrupt connected IoT or hardware services.
Original PR description
We now ensure that the certificate data returned by odoo.com is not empty, to avoid nginx not restarting. Task: 492610 Forward-Port-Of: odoo/odoo#218467 Forward-Port-Of: odoo/odoo#218325
This fixes how the HTML editor handles preformatted text blocks so they behave more predictably. Content pasted into these blocks is now kept as plain text, while list numbers and markers are preserved, reducing formatting issues for users editing website or document content.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: `pre` was not considered paragraph related element. Also it allowed flow content. Desired behavior after PR is merged: `pre` is considered paragraph related element and now it only allows phrasing content also anything pasted within `pre` is now pasted as plain text and list numbering and markers are preserved. task-4766648 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218460 Forward-Port-Of: odoo/odoo#213910
This fix cleans existing and newly entered Peppol endpoint values before checking whether they are valid. It helps upgraded databases avoid errors caused by older partner records that contain unsupported characters.
Original PR description
Commit odoo/odoo@769a7ec5ed4c introduced a restriction to ensure the Peppol Endpoint only contains valid characters. This causes some issues with upgraded database having existing partner with an invalid value. This commit ensures we properly sanitize both Peppol Endpoint existing and new value (before testing its validity). [opw-4925940](<https://www.odoo.com/odoo/project.task/4925940>) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217904
Windows printing now sends documents to the printer one at a time when several print jobs arrive simultaneously. This prevents some documents from failing during busy printing periods and improves reliability for IoT printer setups.
Original PR description
Before this commit, if multiple documents were sent to print at exactly the same time, some of them could end up erroring because the Windows printing API requires us to send one document at a time. After this commit, we use a lock similar to the Linux driver, to ensure that only one document is sent to the printer at once. opw-4829908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218541 Forward-Port-Of: odoo/odoo#218300
Clicking empty space near non-editable navbar buttons in the website builder no longer selects the whole navbar or opens the floating toolbar. This keeps editing behavior cleaner and avoids confusing interruptions for users building website pages.
Original PR description
Steps: - In the website builder, have a navbar with an empty space next to a non-editable button (e.g. the shopping cart or the search button). - Click on the empty space next to the button. As a result the whole content of the navbar gets selected (this might not be visible in Chrome), and the floating toolbar opens. It is not clear why the resulting selection is produced (nor why it is not visible on Chrome), but it is not desirable to have the toolbar opened when clicking on the navbar. But making the non-editable buttons also not user-selectable seems to solve the issue. task-4936596
This fix ensures sales product quantities are passed correctly through configurator processes. It supports accurate configuration behavior, particularly for related enterprise sales workflows.
Original PR description
Needed for enterprise purposes, cf. enterprise PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes unstable automated tests around the link popover in the HTML editor by using full web addresses in those test cases. The change helps keep test results consistent and reduces false failures during development and release checks.
The sidebar now shows unread discussion channels in bold and read channels in muted styling as intended. This makes it easier for users to quickly spot conversations that need attention.
Original PR description
Before this commit, the channel name in the sidebar would be bold when read and muted when unread which is the opposite of the intended behavior. This happens because in https://github.com/odoo/odoo/pull/217629 the condition to make the name bold or muted got extracted into a component method with the incorrect opposite condition for muted. This commit fixes the issue by changing the condition to the correct opposite. task-4938469
Users can now clear a product name and description on an invoice line without triggering an error. This prevents an interruption while editing invoices and keeps invoice line updates working smoothly.
Original PR description
Currently, On removing a product name and its description from the account move line causing an error. Steps to Reproduce: - Install Invoicing app - Navigate to Invoicing>Customers>Invoices - Create…
Currently, On removing a product name and its description from the account move line causing an error. Steps to Reproduce: - Install Invoicing app - Navigate to Invoicing>Customers>Invoices - Create New Invoice and add a product. - Now remove only product name and its description from the account move line(Invoice Line) - click anywhere on the screen. Error: `KeyError: 'name'` Root Cause: since [this commit](https://github.com/odoo/odoo/commit/7e553d25890d1e236123f0fa7e11ce86f59448ab), the method `updateLabel` was removed from the [product_label_section_and_note_field](https://github.com/odoo/odoo/blob/547167ca3ed2ee727ce81c18afaae8aee7a436b4/addons/account/static/src/components/product_label_section_and_note_field/product_label_section_and_note_field.js) component Now, when a user removes the product's description from the invoice line, the `updateLabel` method at [1] is called. In this scenario the value of `[this.descriptionColumn]: value || this.productName` looks like `name= '' || undefined` since this is a falsy condition JS assigns undefined as the value of `name` which is recieved by the onchange method causing an error [1]- https://github.com/odoo/odoo/blob/c04bcaac02b97583f06265e98be8a721538830f6/addons/product/static/src/product_name_and_description/product_name_and_description.js#L131-L135 Solution: This commit prevents the error by ensuring `undefined` value is not sent to the server. sentry-6327760196
This fix ensures mobile shoppers can continue checkout after accepting the Terms and Conditions. The payment button now responds to the visible checkbox in the mobile cart summary, preventing a checkout blocker on small screens.
Original PR description
Commit 260f3fc4 introduced an off-canvas cart summary containing a second "Terms & Conditions" checkbox with the same `id` as the desktop one. When ticking the mobile checkbox, the PaymentButton widget always found the desktop checkbox, which comes first in the DOM, when it should find the one that is currently visible instead. opw-4935641
This fixes visual issues when shoppers add products to comparison while a cookie bar or popup is present. Product animations now go to the correct comparison area, and the compare popover no longer overlaps after the cookie bar is accepted, creating a smoother shopping experience.
Original PR description
Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click…
Steps to reproduce: 1. Enable the cookie bar. 2. Edit the cookie bar to have a link/button at the center. 3. Go to /shop. 4. Click the "compare" button on one product. 5. Scroll down and click "compare" on another product. Issue 1: Product animation goes to the top-left corner. Issue 2: After accepting the cookie bar, the compare button appears but overlaps with the popover. Reason: To cover bottom fixed elements when any modal is open, we added the `o_bottom_fixed_element_hidden` class with the `d-none` property to hide those elements, making them visible once the modal closes. As a result, the compare button hides when scrolled, leading it to redirect to the top-left corner. Additionally, adding a product triggers the applyStyles function of popper.js to handle popover styles. When the cookie bar is accepted and the modal closes, this method doesn't trigger until scroll. This PR aims to resolve animation of product comparision when modal is open by remove the `o_bottom_fixed_element_hidden` class when added to compare products. Additionally, we add debounce leading and trailing params to the `_hideBottomFixedElements` to call function accordingly. task-3877807 Forward-Port-Of: odoo/odoo#214776 Forward-Port-Of: odoo/odoo#182874
The update prevents the developer data view from trying to load raw binary attachment content, such as PDFs, that can break the connection. This keeps the record data tool stable when reviewing attachments in Odoo.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Enable developer mode; 2. go to Settings / Technical / Database Structure / Attachments; 3. open a PDF attachement; 4. open developer tools; 5. click on Record / Data. Issue ----- > Connection lost. Trying to reconnect... Traceback in logger: > `UnicodeDecodeError: 'utf-8' codec can't decode byte ...` Cause ----- Commit 5ef4c07ada1b4 moved the `json_default` function from `date_utils` to `json`, with the purpose of letting it serialize objects besides `date` & `datetime`. When used for raw data of binary files like PDF, it encounters values that cannot be represented in UTF-8, and because `decode` defaults to strict error handling, an exception is thrown. Solution -------- When sending the `read` request to the ORM, only request fields of that aren't of type `binary` to ensure they're serializable. opw-4717657 Forward-Port-Of: odoo/odoo#218401 Forward-Port-Of: odoo/odoo#209702
Website editors can once again see and use parallax background controls inside popup dialogs. This prevents users from getting stuck with a parallax effect they cannot remove when adding certain website sections to a popup.
Original PR description
In [1], we wrongly removed the parallax option for background image that are in a dialog. This lead to some problems (e.g. dropping a snippet with parallax enabled (s_cover) inside a popup doesn't let you remove it). This commit just revert the change concerning the apparition of the option depending on the context. [1]: https://github.com/odoo/odoo/commit/598827afe40e64b27134cb2c9ddbb9421e8a5d82
Auto check-out now uses the employee schedule's local time zone when deciding expected working hours. This prevents employees in non-UTC time zones from being checked out too early when their local workday differs from the UTC date.
Original PR description
**Issue** The auto check out cron was using the check in time in UTC to determine the excepted working hours and the previous attendances. For example: - have an employee with a working schedule using a UTC+8 timezone. - check-in on a monday before 8am (0:00 UTC) in the employee's tz. - the auto check-out cron closes the attendance immediately because there are no working hours for the attendance's check in day in UTC (Sunday). **Change** Use the date of the check-in localized in the tz of the calendar used by the attendance's employee to determine the previous worked hours for that day and the expected worked hours. opw-4654847 Forward-Port-Of: odoo/odoo#212594
The HTML editor’s font size field now adjusts its text color properly when dark mode is enabled. This improves readability and keeps the editing experience consistent for users working in darker interface themes.
Original PR description
Purpose of this PR: - Backport a [PR #206008](https://github.com/odoo/odoo/pull/206008), which ensures that the font-size input now changes its color appropriately in dark mode. task-4897771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215865
This fix restores the Dynamic Placeholder option in the mass mailing email editor when users type /field. It ensures marketers can insert personalized fields while keeping mass mailing-specific options like Rating available.
Original PR description
Description of the issue this PR addresses: - In saas-18.4, the "Dynamic Placeholder" command stopped appearing when typing `/field` in the email editor's powerbox. - This issue appears after the changes made in this Commit https://github.com/odoo/odoo/commit/3a02143e4d91c6f46110f22f1be84b77e7fb0bb6. Current behavior before PR: - The `_getEditorOptions` method in the `mass_mailing editor` replaced the default powerboxItems with its own (e.g., for Rating), which unintentionally removed built-in commands like "Dynamic Placeholder". Desired behavior after PR is merged: - The overridden powerboxItems now extend the default ones instead of replacing them. This ensures that both built-in commands (e.g., "Dynamic Placeholder") and custom ones (e.g., "Rating") are available in the powerbox. task-4901178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents accidental layout damage when users press Backspace in columns or partially selected table areas. It keeps editor placeholders and content containers intact so visual hints stay correctly positioned and table cells remain editable as expected.
Original PR description
**Current behavior before PR:** - Pressing backspace while a column is selected could cause the column hint to be incorrectly positioned. This happened because the base container inside the column was removed during the backspace action. - When a table row or column was not fully selected, pressing Backspace would replace the contents of the selected `td` elements with a `br` tag. **Desired behavior after PR is merged:** - If the base container is removed during backspace, it is now reinserted to ensure the column hint remains correctly positioned. - Pressing Backspace in a partially selected row or column now replaces the content of the selected `td` elements with a base container instead of a `br` tag. task:4783325 Forward-Port-Of: odoo/odoo#218013 Forward-Port-Of: odoo/odoo#209226
The Indian state previously shown as "Orissa" in contact address selections is now correctly displayed as "Odisha". This aligns Odoo's country/state data with official Government of India naming and avoids outdated information in customer and company records.
Original PR description
<b>Steps to reproduce:</b> 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country "India", then open the State dropdown. 4. Observe that "Orissa" appears instead of the updated name "Odisha". <b>Issue:</b> As per [Government of India guidelines](https://www.mha.gov.in/sites/default/files/2022-08/odishaAlterationAct2011%5B1%5D.pdf), the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in the state selection. <b>Solution:</b> Update the name of the state from "Orissa" to "Odisha" in state records. <b>opw-4935633</b> Forward-Port-Of: odoo/odoo#218342
Fixed an issue where manufacturing orders created from make-to-stock order sales did not show the related sales order link, even though the sales order linked to the manufacturing order. This makes order tracking clearer and more consistent for users moving between sales and manufacturing records.
Original PR description
Currently, with an MTSO rule, the smart button from the Sale Order to the Manufacturing Order was available. However, the reverse link (from the MO to the SO) was missing. But they share the same…
Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.
But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.
It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
- Select the rule with the production usage
- Set its supply method to "MTSO"
- Create a storable product “P1”:
- routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO
Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.
opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746
Forward-Port-Of: odoo/odoo#217947
Forward-Port-Of: odoo/odoo#204276This update adjusts website sales tests so previously sold demo products are archived before the test runs. This prevents demo data from causing false test failures, improving reliability of validation for the online shop module.
Original PR description
Archive previously sold products to make sure they do not make the test fail when demo data are installed. runbot build error 163667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218423
The website editor's custom color picker now correctly applies the hue a user clicks, such as green, instead of producing a transparent black color. This restores expected color selection behavior and makes page styling more reliable for editors.
Original PR description
This commit adds back functionality that was present in <=18.3 versions. Steps to reproduce the issue: - Open Website and start editing; - Drop a 'text - image' snippet and click on it - Open the background colorpicker - Click on a green hue => We don't get green, we get a fully transparent black, and to get green we have to change the saturation and value, which shouldn't be the case. Also, when no color is selected, the red color should be highlighted.
This fix ensures employee work calendars are checked against the correct company on the employee record, not only on related HR version data. It helps prevent assigning calendars from the wrong company in cases where company fields differ, such as contract templates.
Original PR description
The check_company of the resource_calendar field was only on the hr_version model but should also be on the hr_employee model as the two company fields are not necessarily related (ex: contract templates). task-4894155 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
Products that are allowed to sell when out of stock now show as available for regular delivery, even when in-store pickup is also enabled. This prevents customers from seeing an incorrect delivery-unavailable message and helps avoid lost online sales.
Original PR description
Steps to reproduce: 1) Configure a product and allow selling when out of stock 2) Publish any delivery method 3) Publish the Pickup in-store delivery method 4) Check the product page of the created product Problem: It is shown that the product is not available for delivery even though we allow selling it when out of stock This commit shows that a product is available for delivery (not for in_store one) if allow selling when out of stock is enabled. opw-4792024 Forward-Port-Of: odoo/odoo#218298
The online shop now loads correctly when the search box is enabled or disabled from the backend. This prevents an error page for visitors and lets administrators manage the search box visibility safely.
Original PR description
**Before this PR:** - Toggling the active field of the search box view from the backend caused a traceback on the shop page when loading the frontend. **After this commit:** - The shop page now loads correctly even when the search box view is deactivated or reactivated via the backend. The toggling behavior works as expected without raising errors. **opw - 4918722** Forward-Port-Of: odoo/odoo#217263
This fixes an issue where content pasted from apps like Discord could add invisible blank areas in the Odoo editor and disrupt the “Type '/' for commands” placeholder. The editor now cleans pasted blocks correctly, preserving useful line breaks while removing empty or improperly styled content.
Original PR description
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type…
Steps to Reproduce : - Open the Discord app - Copy the text written in multiple lines - Paste it in the Odoo Editor - Click below any line or empty space - You will notice that the placeholder "Type '/' for commands" is getting destroyed. Description of the issue this PR addresses: - The issue was caused by visually empty `<div>` elements included in pasted content and not converted into baseContainer. - This regression was introduced in commit [#196481](https://github.com/odoo/odoo/pull/196481/files?diff=split&w=0#diff-1b8ed5b7d66a870806b1e7400a0d6cb9ba8810327824244eca868be9583b7fd9L467-L477), which stopped replacing blacklisted tags like `<div>` with `<p>`. - As a result, cleanForPaste no longer strips inline styles from `<div>` elements. Current behavior before PR: - Pasted content includes non-visible `<div>` elements. - These empty blocks occupy space without contributing visual content. - Inline styles from copied content remain intact. - `<div>` elements are not replaced with valid block tags. - Placeholder rendering is broken in these ghost spaces. Desired behavior after PR is merged: - Non-empty `<div>` elements are replaced with a baseContainer element. - Empty `<div>` elements are automatically removed from pasted content. - This restores the expected cleaning behavior, removes unwanted styles, and preserves line breaks. task-4805536 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210797
The website editor now correctly accepts negative shadow values when adjusting design options. This prevents an error from interrupting users who fine-tune header or element shadow styling.
Original PR description
Since website refactor [1], negative values for the shadow option were not properly handled, leading to a traceback. This commit updates `parseShadow` regex to correctly accept all negative shadow values. These negative values are crucial for precise shadow styling, enabling effects like inner shadows or shadows that extend inward or upward. Steps to reproduce: - Edit website - Click on header - Modify shadow offset to a negative value - A traceback occurs [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This fixes a recent issue that limited menu icons to PNG files only. Businesses can once again use common image formats such as GIF, JPEG, SVG, ICO, and WebP for menu icons, restoring the flexibility available in earlier versions.
Original PR description
Description of the issue/feature this PR addresses: PR #135607 breaks support of image types other than `png` for menu icons. This puts back the support for previously supported image types. Current behavior before PR: You can't use a menu icon which has a type other than `png`. Desired behavior after PR is merged: You can use `gif`, `ico`, `jfif`, `jpeg`, `jpg`, `svg` and `webp` files like version `16.0`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218131
Manufacturing orders with by-products could incorrectly create and validate an extra stock move when produced quantities exceeded the original demand. This fix ensures tiny rounding differences no longer prevent related stock moves from merging, avoiding overstated by-product quantities and inventory inaccuracies.
Original PR description
### Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand…
### Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand confirm an MO for 1 unit of FP - On the by product line produce 10 instead of 1 - Produce All #### > 19 units of by products were produced: The initial by-product move was validated for 10 units and an extra move with a quantity of 9 was automatically created and validated aswell. ### Cause of the issue: Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation: https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move. ### Note: The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by commit 784f1511acc4352905a61f9bd90aecb78e8558ec opw-4846289 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217806 Forward-Port-Of: odoo/odoo#215372
This fixes an unreliable automated test for adding a new line in detailed stock operations. The change helps prevent false test failures, supporting smoother validation and delivery of stock-related updates.
Original PR description
The `test_add_new_line_in_detailled_op` fails in 18.0+ since clicking on the head of the modal content will trigger a web_read before the records has been updated in db. So that the last applied change disappear. This commit attempt to clean the tour to be more reliable. runbot-113534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216860 Forward-Port-Of: odoo/odoo#216645
Fixes an issue where completed manufacturing orders could not be closed from the Shop Floor view after their operation was marked done. This ensures production orders are properly finalized and removed from the active work list, reducing manual follow-up for manufacturing teams.
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [1]. To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [1], in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [1], the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in [1] where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of [1] because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [1]: 10ed12241365942914885dff953049303b9ed94f Enterprise: https://github.com/odoo/enterprise/pull/86905 opw-4800147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215848 Forward-Port-Of: odoo/odoo#212885
Employees can now post expenses even if they do not have a work email address recorded. This avoids unnecessary blocking because the related contact can be created without relying on that email field.
Original PR description
- removed work email constraint while posting the expense as the partner is now created without the need of work email --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218279 Forward-Port-Of: odoo/odoo#212211
Work order lists in Manufacturing can once again be edited in batches. This fixes an accidental change that removed multi-editing, helping teams update multiple work orders more efficiently.
Original PR description
Multi-edit was disabled from the WO list view by mistake in commit: https://github.com/odoo/odoo/commit/5767cf0c0cbf2a4130430cd92a3cba8891b84510 Therefore, it has been re-enabled. Task: 4900236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216143
This update corrects how employee version deletions are validated so archived versions do not incorrectly affect the check. It also handles deletions involving multiple employees, helping ensure every employee keeps at least one active version as required.
Original PR description
"An employee must always have at least one active version." The constrain had two issues: 1. it took into account the number of archived versions selected for deletion, but it shouldn't. 2. It assumed a single employee for all versions getting deleted. Task-4903960
This fixes intermittent failures in automated live chat rating checks by ensuring the chat session is fully created before it is closed and rated. It helps keep chatbot rating flows consistently verified, especially under slower system conditions.
Original PR description
Chatbot rating tours can sometimes fail. They all share the same steps: start a chat, close the chat, then rate the agent. Before closing the chat, the tours check that the message is present in the DOM, assuming it has been posted, then close the chat window. However, this is not enough to guarantee the thread was properly created. Initially, a temporary thread is shown. When the user sends the first message, a temporary message is posted on that thread while the real thread is created asynchronously. As a result, closing the chat after checking the message in the DOM doesn’t guarantee the window belongs to the persisted thread. If it doesn’t (due to slow network or high CPU load), the rating panel never shows because the real thread was never closed. This commit fixes the issue by waiting for the persisted thread to be created before closing the chat. fixes runbot-159683 Forward-Port-Of: odoo/odoo#218318
Partnership products published on the online shop are now visible and available for purchase again. This restores the expected eCommerce flow for customers and prevents missed sales of partnership-related services.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a partnership product; 2. publish it on eCommerce; 3. as Portal or Public user, open /shop; 4. if visible, buy it & go back to /shop. Issue ----- Product is not available on /shop (anymore). Cause ----- Partnership tracking (partnership created on order) on service products isn't made saleable. Solution -------- Add `partnership` to `_get_saleable_tracking_types`. opw-4926679 Forward-Port-Of: odoo/odoo#217863
This update addresses unnecessary hidden fields across several country-specific accounting and compliance views. It keeps stable-version tests passing while reducing the risk of issues for customers with customized views.
Original PR description
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216095 Forward-Port-Of: odoo/odoo#206026
This fixes an issue where changing the size of selected heading text in the website builder did not take effect when the heading already had a predefined size style. Business users can now adjust heading sizes more reliably while editing website content, reducing formatting frustration and manual cleanup.
Original PR description
Steps to reproduce: - In the website builder, drop a snippet with a heading that has a font-size class (e.g. `<h2 class="h4-fs">`). For instance "Key benefits" - Select the text of the heading and try to change its size => It doesn't work. The class remains, and no span child is created. Until [1], in such a case, a span child was created, but the original class was not removed. This is a best effort with the current editor: ideally, the new class should be applied on the heading tag itself (to avoid weird line heights). The behavior was introduced with [2] but was not replicated in the html_editor refactoring [3], which did not need it at that time. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [2]: https://github.com/odoo/odoo/commit/194f73a9bbad8c3c3fb5c378e7bdfa704aaacdc0 [3]: https://github.com/odoo/odoo/commit/97117e70a1766ad24f5ec14ffef303127d56b76b task-4367641
This fixes an intermittent failure in the automated test for the website live chat bot conversation flow. It ensures the test waits for the chat bot to actually finish its delayed response handling, improving confidence in live chat quality checks without changing customer-facing behavior.
Original PR description
Before this commit, the `website_livechat_chatbot_flow_tour` tour was sometimes failing. The intent it to ensure the chat bot stops until the user fully wrote his answer. The flow is the following: -…
Before this commit, the `website_livechat_chatbot_flow_tour` tour was sometimes failing. The intent it to ensure the chat bot stops until the user fully wrote his answer. The flow is the following: - User sends a message (first part of his answer) - User starts typing: the chat bot waits - After some time, the user didn't finish his answer afterall, the chat bot continues. The chat bot uses the `_processAnswerDebounced` function to delay the processing of the step. However, the tour relies on `setTimeout`, expecting to come after the debounce delay. However, multiple messages are sent, and the debounce delay is postponed. As a result, the assertion is made too early, making the test fail. This commit fixes the issue by awaiting a deferred, resolved when the chat bot actually executes the debounced function. fixes runbot-113948,227675 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#218222 Forward-Port-Of: odoo/odoo#218153
The Belgian payroll double holiday pay report now uses the correct payslip-based label instead of referring to the 13th month. This makes generated payroll documents easier to identify and reduces confusion for HR and employees.
Original PR description
Originally, the name structure for double holiday follows "13th Month -[Legal Name] -[year]". It has been renamed to "[Payslip name]- [Legal Name] -[year]" . Forward-Port-Of: odoo/enterprise#88732
Appointment request notifications now include CC contacts when manual confirmation is enabled. This ensures teams or stakeholders copied on an appointment are informed as soon as a request is submitted, reducing missed follow-up and confusion.
Original PR description
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go…
…ith manual confirmation **Steps to reproduce:** - Install Appointement app - Edit an appointement appointment type - Set manual confirmation for the appointement type - Add CC contact as well - Go to the appointement website (/appointement) - Create an appointement and submit it - Nothing is sent to CC contact when the request is made **Issue:** Process was designed to only send notification mails to the CC contacts (`message_partner_ids`) when the request was approved or cancelled (`booked` or `cancelled` appointment_status) but not for `request` when using manual confirmation. This is also quite problematic if `Availability on` is set to resources, as no confirmation mail is sent to anyone in that case (when no CC is specified, there is no other user than the requester). The observed behavior is due to the new process used when making appointement, previously in 17.0 the state was directly set to 'booked' so the mail was directly created and no further mail was sent unless the user explicitly cancelled its appointment. **Fix:** Added 'request' to the filtering on 'appointment_status' when adding the mail templates. Adapted field description and mail templates for clarity. related: cc field description https://github.com/odoo/enterprise/commit/adf47c32ee190dbf98c266d0816c8d03c8cd3e4f appointment_status https://github.com/odoo/enterprise/commit/3c64aa6dcd191248f0806c0b84ffa416d455fde4 request template https://github.com/odoo/enterprise/commit/2316947a0251709f3e469fea996ffac8f4623d98 opw-4658521 Forward-Port-Of: odoo/enterprise#88042 Forward-Port-Of: odoo/enterprise#86710
Emails sent with attachments to accounting journal aliases now process correctly in multi-company setups with separate alias domains. This prevents errors when accounting attachments are centralized in Documents, ensuring vendor bills and similar records are created and parsed as expected.
Original PR description
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with…
Before this commit ------------------ if a user had a multi-company setup with a different alias domain set for each company, a multi-company error could happen. It happens when sending a mail with attachment to an accounting journal alias. The exact conditions required to enable the option to centralise all attachments in Documents for the journal in question. steps to reproduce: 1. clean DB with documents_account installed 2. create a 2nd company "company 2" 3. create an alias domain for company 1 "alias.company1.com" and another alias domain for company 2 "alias.company2.com" 4. in documents, create a "finance" folder for company 1 (i.e. set the company_id field on the folder) and another folder for company 2 5. configure the settings for both companies so that all attachments are centralized in documents for accounting, in the respective folder for that company 6. create an alias for some journals in company 2 (e.g. vendor-bills@alias.company2.com) 7. send an email with attachment to that alias -> you will get a multi-company error After this commit ------------------ Sending a mail with attachment to an accounting journal alias creates the account_move as expected. The attachment is parsed as expected. opw-4727873 opw-4655559 opw-4746321 opw-4766895 Forward-Port-Of: odoo/enterprise#89411 Forward-Port-Of: odoo/enterprise#84997
Subscription pricing or rule conditions that depend on a minimum product quantity now only apply once that quantity is actually reached. This prevents customers from receiving rule-based terms too early and helps keep subscription offers aligned with intended sales policies.
Original PR description
Rules applicable above a specific product quantity should not be considered unless the minimal quantity is reached.
This fix prevents an error when generating Peru Stock Move PLE valuation reports. Users can now run the PLE 13.1 report for Peruvian companies without the report failing due to missing product category data.
Original PR description
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to…
Currently, an error occurs during the valuation of the Stock Move PLE reports. Steps to Reproduce: - Install the `l10n_pe_reports_stock` module. - Create a `new company` with the country set to `Peru`, and switch to this company. - Go to `Receipts` in `Inventory`, create a `new receipt`, and `validate` it. - Go to `Valuation` and click on `PLE Reports`. - Select the `start date` as the day after today, and click on `PLE 13.1`. `KeyError: 'category'` This error occurs during the valuation of the Stock Move PLE reports. In the query, we retrieve product_template.categ_id as category_id [1], but later category [2] is used to access category_id. Since the category key is not present in the line, this causes the error. [1] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L241 [2] https://github.com/odoo/enterprise/blob/95d20fca13efa0977018b0dc260efd410891fce6/l10n_pe_reports_stock/wizard/stock_move_ple_report.py#L303 This commit ensures that category_id is used in place of category for safe evaluation. sentry-6723761615 Forward-Port-Of: odoo/enterprise#89379
Users can now share shortcut folders from the cog menu next to the breadcrumbs in Documents. This fixes a missing sharing option and removes unused code, making folder sharing more consistent.
Original PR description
Before this commit, the share action in the cog menu (next to the breadcrumbs) wasn't available for shortcut folders. This commit fix this issue. This commit also removes some dead code. Task-4897840 Forward-Port-Of: odoo/enterprise#89161 Forward-Port-Of: odoo/enterprise#88512
This update ensures the invoice option is selected before validating Italian point-of-sale orders, preventing a validation error that could block sales completion. It also removes a duplicate line in the UrbanPiper POS integration, with no expected change for users beyond cleaner behavior.
Original PR description
## After this commit: - It ensure invoice checkbox is selected before validation, preventing the error and allowing the order to validate correctly. - Removed repeated line in `pos_urban_piper`. Runbot [link](https://runbot.odoo.com/odoo/runbot.build.error/159985) Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4916349) runbot-159985 task-4916349 Forward-Port-Of: odoo/enterprise#90018 Forward-Port-Of: odoo/enterprise#89486
Spanish Model 349 BOE reports no longer include rectification lines for bills and credit notes that fully cancel each other within the same reporting period. This avoids incorrect tax report entries while preserving expected rectifications for prior-period bills.
Original PR description
# How to reproduce the issue On a **l10n_es** fiscal position: - Create a bill for the current period and then create a credit note for this bill. - In the tax report, under model 349, download the BOE report. Since the bill has been fully canceled within the same period, no rectification line should appear in the BOE report (correct behavior). - Create a bill from a previous period. - Create a credit note for this bill in the current period. - Download the BOE report from model 349. A rectification line appears for the previous period bill, which is expected. However, a rectification line also appears for the current period bill, which is incorrect, as the bill was canceled within the same period. This commit prevents moves from the current period from being included as rectification lines in the BOE report. opw-4895636 Forward-Port-Of: odoo/enterprise#89624 Forward-Port-Of: odoo/enterprise#89382
The India reports now use the official state name “Odisha” instead of the outdated “Orissa”. This keeps tax reporting labels aligned with Government of India terminology and avoids confusion for users reviewing statutory reports.
Original PR description
Issue: As per Government of India guidelines, the state name was officially changed from "Orissa" to "Odisha" in 2011. However, Odoo still uses the outdated name in report. Solution: Updated the records from "Orissa" to "Odisha". opw-4935633 Forward-Port-Of: odoo/enterprise#89947
Salary package offers that start in a future month now generate a payslip beginning on the contract start date instead of the current month. This prevents payroll documents from being created outside the employee's contract period, reducing errors during offer and payroll setup.
Original PR description
When creating an offer with a contract date start in the future, the payslip created is still set at the current month, so the contract is outside the payslip. This is fixed by creating a payslip with date_from equal to the contract_date_start. Task: 4903936
Scanning a product package in the Barcode app now updates the matching open receipt line instead of creating a duplicate line. This helps warehouse teams process receipts more accurately when products are handled in different package sizes.
Original PR description
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable…
### Issue: When processing a picking form the barcode, uncompleted lines refering to a product are not updated by scanning a different packaging. ### Steps to reproduce: - In the settings enable "Units of Measure & Packagings" - Create a product using the base Unit as uom and allowing pack of 6 aspackaging (optional) - Inventory > Configuration > Product > Units & Pacakagings - Click on pack of 6 > Packaging Barcodes > New - Create a new one for your product - Create and confirma receipt for 6 units of your product - Go to the barcode app and scan a pack of 6 #### > A new line 1 pack of 6 was created rather than updating the already existing one. ### Cause of the issue: When the packaging is scanned, we will call the `findLine` of the `BarcodeModel` in order to determine if there is already an existing line that could absorb the scanned qty. However, this call currently requires the uom of the barcodeData to coincide either with the line uom or its referred packaging to be a valid candidate: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1748-L1753 ### Note: This additional check was added in a9a20f8ec5a7883a08eb4bea15dbf3c4cc97caac when the uom and packagings were refactored and merged together. However, it is really unecessary since the system can handle different uoms via these lines: https://github.com/odoo/enterprise/blob/fb405cee9b183d697e3cf0e33bb49371b87cb1ac/stock_barcode/static/src/models/barcode_model.js#L1450-L1466 ### opw-4866981 Forward-Port-Of: odoo/enterprise#89453 Forward-Port-Of: odoo/enterprise#88494
This fix stops Point of Sale auto-configuration from automatically assigning a newly detected scale device when an IoT Box may have misidentified a connected Blackbox terminal during first startup. This prevents incorrect store settings and avoids manual cleanup after the IoT Box restarts and recognizes the device correctly.
Original PR description
If on first boot after flashing the iot box a blackbox is connected the iot box doesn't have the blackbox driver so it's identified as Adam scale With the pos_iot auto configuration we would first send it as a scale to the database and it would be set as a scale to the selected pos config. After odoo restart on the iot box it gets detected as blackbox correctly and its name changes. Now after it's sent to the db the user ends up with a blackbox in the scale field in PoS config. This PR removes the automatic scale configuration so that doesn't happen Forward-Port-Of: odoo/enterprise#89888
Manufacturing orders can once again be closed directly from the Shop Floor after their operation is marked done. This prevents completed work from getting stuck in the interface and helps production teams keep order statuses accurate without switching screens.
Original PR description
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the…
### Steps to reproduce: - Create a product P with a bom with an operation in the Assembly line - Create and confirm an MO for 1 unit of P - Open Shop Floor, Mark the operation as Done - Click on the All MO tab > The operation was removed from the Assembly line - Click on "close production" #### > Nothing happends while the MO should be marked as done and disappear ### Cause of the issue: The issue has been introduced by commit [X](10ed12241365942914885dff953049303b9ed94f) To be more precise, clicking on the "Close production" button will launch a call of the `validate`. In case of `mrp.production` records, this call will first launch a call of the `pre_button_mark_done` and then (prior to the change) add the record to the validation Stack for real Validation: https://github.com/odoo/enterprise/pull/79918/commits/10ed12241365942914885dff953049303b9ed94f#diff-7695d0af56f8efc3200fc5a693b797de9314165f4754bb2054d25809381c0ccdL504 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L530 Prior to commit [X](10ed12241365942914885dff953049303b9ed94f), in our use case, the `pre_button_mark_done` would simply return `True` as no action need to be proceed prior to the `button_mark_done` and the porduction would be added and closed by the real validation. However, since commit [X](10ed12241365942914885dff953049303b9ed94f) the record is simply set to the validated state and not added to the validation stack... That satement is simply incorrect: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L503-L505 In the most general usecase, our mrp record is in `to_close` state and is not expected to be validated by the `pre_button_mark_done` even if this call returns `True``. What is true however, is that in the exceptional use case treated in commit [X](10ed12241365942914885dff953049303b9ed94f) where you are in the `always` backorder setting and where you need to create a backorder, the MO will be entirely processed by the `pre_button_mark_done`: https://github.com/odoo/odoo/blob/6542b0a5a58324f532a4ae1e0c630ca4fe2f77d7/addons/mrp/models/mrp_production.py#L2142-L2145 and hence should not be marked as done once more (otherwise it would raise multiple errors such as sn uniqueness,... (as the mo has already been validated)). ### Fix: The double validation did not happen prior ot the change of commit [X](10ed12241365942914885dff953049303b9ed94f) because we did not skip redirection at the time: https://github.com/odoo/enterprise/commit/154eec919faac0725b90b830adf499df375e8e81 https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L497-L502 returning the record before even adding it to the real validation stack. However, since we do not want to be redirected to the back end we propose to return the information that the record has been validated by the `pre_button_mark_done` and avoid the call of the real validation using the mechanism already in place: https://github.com/odoo/enterprise/blob/9484f1259393bda24e982fdfec87909c27280728/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L521-L524 Commit [X](10ed12241365942914885dff953049303b9ed94f): 10ed12241365942914885dff953049303b9ed94f Community: https://github.com/odoo/odoo/pull/212885 opw-4800147 Forward-Port-Of: odoo/enterprise#88525 Forward-Port-Of: odoo/enterprise#86905
This update documents hidden fields across several localization and payroll screens so automated checks pass consistently in stable versions. It reduces maintenance risk while preserving current behavior for customers and custom views.
Original PR description
Before this commit, several invisible fields were present in the views, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031 This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. Forward-Port-Of: odoo/enterprise#88643 Forward-Port-Of: odoo/enterprise#83421
Offer processing for applicants now creates only one salary contract version when a new employee record is created. This avoids duplicate versions at the end of the signature process, making employee offer records cleaner and easier to manage.
Original PR description
Current Behavior: When you send an offer to an applicant it will create two versions at the end of the process: https://tinyurl.com/253j3683. Behavior after PR is merged: When you send an offer to an applicant it will only create one version* for the employee created from the applicant. Change: Removed the unnecessary initial version created for fresh employee records coming from applicants' offers. *: note that this new version will be active, even when awaiting full signature, this might be acceptable since the fresh employee record would be archived, which is different from existing employees offers, where the employee remains active, and the new version is archived till full signature. Task-4903960