Daily updates from Odoo
Wednesday, September 10, 2025
46 changes · saas-18.4
Enhancements to existing features
Invoice notification emails are now easier to read, with a simpler layout and fewer invoices shown at once. The email also avoids blank or confusing placeholders by only showing invoice details and greetings when the related data is available.
Original PR description
Enhances the einvoice email template for better readability and handling of missing data. - Switch table layout to a more linear view mode - Display invoice number, vendor name, date, and total only if values exist and remove values if no values are found - Use dynamic greeting to mention company name or remove placeholder if doesn't exist - Reduce maximum invoices shown to 5 to improve email length - Changed view invoices redirection button 4985307 Forward-Port-Of: odoo/odoo#226092
The Peppol registration wizard now includes clearer help text explaining how certain registration details are used. This helps users provide the right information with more confidence when setting up electronic invoicing.
Original PR description
…ion wizard. Give move information on what the registration information are used for. task-none Forward-Port-Of: odoo/odoo#225730
Users with Invoicing & Banks access can now start online bank synchronization when a bank journal is set up for online feeds and not already connected. This makes it easier for invoicing teams to connect bank accounts without needing broader accounting permissions.
Original PR description
Before this commit: - Users with "Invoicing & Banks" access rights could not create a bank synchronization, and the "Connect Bank" button was not visible. After this commit: - Users with "Invoicing & Banks" access rights can now create a bank synchronization if the journal has "Bank Feeds = Online Synchronization" and the bank is not yet connected. - The "Connect Bank" button is now visible to them. task-4840544 Forward-Port-Of: odoo/enterprise#87408
Vendor bill uploads now warn users when the bill GSTIN does not match the selected company, helping prevent filings under the wrong entity. GSTR-2B matching also handles duplicate invoice reference numbers in draft purchase documents so automated processing can continue without getting stuck.
Original PR description
Use Case 1 – Bill Upload/Scan - Issue: When scanning or uploading vendor bills, system allows upload even if the bill’s GSTIN does not match the company GSTIN. This can happen when multiple companies share the same name but have different GSTINs under the same PAN. - Solution: Add a warning if the bill’s GSTIN doesn’t match the company GSTIN: *"It seems Bill’s GSTIN doesn’t match this company. Please verify before proceeding.”* Use Case 2 – Duplicate IRN in GSTR-2B Matching - Issue: Cron job gets stuck when duplicate IRN exists in both draft purchase documents and fetched GSTR-2B data. - Solution: Include draft purchase documents having IRN in the matching process for the current period, so duplicate warnings are skipped and processing continues smoothly. Task ID: 4862214 Forward-Port-Of: odoo/enterprise#92948
Resolved issues and error corrections
Website editors now see navbar logo height changes right away while editing, instead of only after saving or reloading assets. This makes logo sizing adjustments more reliable and reduces confusion when customizing a website header.
Original PR description
Steps to reproduce: - Website > Go to Website > Edit - In the sidebar: Navbar logo, change Height - Before: the logo size does not change until clicking Save (or after bundles reload) - After: the logo resizes immediately while editing Since [1], the header logo is rendered with width and height attributes to reserve space and reduce CLS. But since [2], the `width` and `height` attributes have been removed and converted to inline styles, which take precedence over the CSS stylesheet. This commit addresses this issue. [1]: https://github.com/odoo/odoo/commit/d80b8cbc28b6e9d16608f9ecfcf4b360d0c792c7 [2]: https://github.com/odoo/odoo/commit/cb2510f4e525192e4b3d5d673218775c2d9d174e
A small error in the Indian electronic invoicing process was corrected so invoices can be sent without triggering an unexpected failure. This helps businesses using India localization avoid disruption when submitting signed invoice data.
Original PR description
In this commit- --- Fixed a typeError in l10n_in_edi_send_invoice method Replaced - incorrect syntax `data.get['SignedInvoice']` with `data['SignedInvoice']`. opw-5071703 Forward-Port-Of: odoo/odoo#226106
This fix makes the website builder behave correctly when editing pages in right-to-left languages such as Arabic. Dragging and resizing columns in grid layouts now stays aligned with the cursor, reducing layout mistakes for users building localized websites.
Original PR description
**[FIX] html_builder: fix resizing columns in rtl mode** This commit fixes issues in edit mode when resizing columns or using grid mode on websites displayed in a right-to-left (RTL) language like Arabic. task-4815296 Forward-Port-Of: odoo/odoo#224313 Forward-Port-Of: odoo/odoo#217338
This fixes a mail discussion issue where an error message could remain visible after messages successfully loaded on retry. Users who temporarily lose connection will now see the thread return to its normal state once loading succeeds.
Original PR description
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch…
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch attempt succeeds, the flag is not reset. As a result, the UI may continue to show an error state even though the data has successfully loaded. **Steps to Reproduce:** - Open a thread with many messages. - Go offline. - Scroll up to load older messages → failure message appears. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> - Go back online and click Retry → messages load successfully. - Scroll again → failure message still appears, even though you’re online. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> **Current behavior before PR:** After a failed attempt to fetch messages in a thread, the `hasLoadingFailed` flag remains set to `true`. Even if the user goes back online and the subsequent fetch succeeds, the UI continues to show a failure state. **Desired behavior after PR is merged:** After a successful fetch of a thread’s messages, the `hasLoadingFailed` flag is reset to `false`, ensuring the UI no longer shows a failure state once the data has been correctly loaded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226145 Forward-Port-Of: odoo/odoo#222001
Kiosk self-ordering now only shows online payment methods that are properly configured for that kiosk. This prevents customers from paying with an unsupported option and ending up with an order that appears confirmed but is not handled correctly by preparation workflows.
Original PR description
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are…
Currently, you are able to see online payment methods in the kiosk if you have at least a terminal method registered. Since you're able to see them you can also select it. Once paid you are redirected to the confirmation screen saying that the order is being prepared but the order is not sent to the preparation display, although the order is paid in the backend. Steps to reproduce: ------------------- * Create a payent method using terminal, for easier setup use stripe, you'll only need to setup serial number on the payment method but you do not need to do the whole stripe setup * Create an online payment method (use demo for example) * Change the kiosk settings to use those two payment methods * Change the settings of the preparation display to use the kiosk * Open preparation display * Open kiosk, make on order, and select the online payment method * Scan QR code and pay > You are redirected to the confirmation page saying that the order is being prepared while not sent to the preparation display Why the fix: ------------ The fix to send the order to the backend is in the other part of this fix. Here we decide to only allow to use the online payment methods that have been set on the config. Previously if two were existing but only one setup you were able to select any of them. We also make a change to the `filterPaymentMethods` method. This method is called when pressing the pay button and is indirectly responsible for the fact that if there's only one payment method then we directly start the payment process. Prior to this fix if we only had a terminal method setup and clicked to pay an order we directly had the screen telling us to follow the instructions on the terminal. However if we only had a online payment method, when clicking on pay, we would directly have the screen prompting us to pay at the register, we could never select the payment method. With the fix, when there's only one payment method and it's online, clicking on pay will show the qr code. opw-5001998 Enterprise: https://github.com/odoo/enterprise/pull/92825 Forward-Port-Of: odoo/odoo#225851 Forward-Port-Of: odoo/odoo#223689
Product pages could show a forbidden error to public visitors when certain extra product fields were enabled. This update ensures those configured fields load correctly, keeping product pages accessible for shoppers.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable debug mode; 2. go to Website / Configuration / Websites; 3. open first website; 4. open Product Page Extra Fields tab; 5. add Icon (Product); 6. go to a product page as Public User. Issue ----- > **403: Forbidden** > [!Note] > For this issue to occur, the extra field cannot be loaded into cache yet, making it difficult to reproduce in versions before 18.3. As of 18.3, access rights are checked regardless of cache status. Cause ----- It's possible to add extra fields that don't allow access to public users by default. Solution -------- In the `ecom_show_extra_fields` template, retrieve the field values in `sudo` mode. opw-5031708 Forward-Port-Of: odoo/odoo#225352
This fixes an issue where updating a public holiday could cause an error when two approved time off requests shared the same dates but treated public holidays differently. HR teams can now manage public holidays and overlapping leave requests without triggering a system crash.
Original PR description
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to…
When two timeoff (one with Ignore Public Holidays and the other without) have the same dates, if you modify a public holidays that happend during that time, it will trigger a traceback. Steps to reproduce: ------------------- * Marc demo and Abigail Peterson using the same calendar * Create a "Paid time off" leave for marc demo: June 19 - June 20 * Create a "Extra time off" for abigail: same date * Update Time off type "Extra Time Off" to "Ignore Public Holidays" * Approve both leave request previously created * Create public holidays on June 19 --> traceback Observation: When both time off have the same dates it will overide the value in the dictonary https://github.com/odoo/odoo/commit/0d846ecd1ec7ff5149d580d3494b1a4bab1e68d2#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R464 and when it will try to call the employe_id it will trigger the traceback https://github.com/odoo/odoo/commit/f72ac3a14d76d4fb53ec3a092d08afafe4c35888#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R561 Why the fix: ------------ Added a new key on work_days_data to avoid the collision of two similar timeoffs. opw-4933820 Forward-Port-Of: odoo/odoo#225443 Forward-Port-Of: odoo/odoo#221942
This fixes an editor issue where pasting the same hyperlink twice in a row could incorrectly combine the links and trigger an error. The editor now only merges simple text formatting elements, keeping pasted links separate and stable.
Original PR description
Steps to reproduce: - Copy a valid hyperlink (e.g., https://example.com). - Paste it into the editor. - Without changing the selection or moving the cursor, paste the link again. - Inspect the DOM: both links are merged into single tag, causing a traceback. Description of the issue/feature this PR addresses: - When pasting the same hyperlink multiple times without moving the cursor, editor merged them into a single anchor tag, which triggered a traceback. This appeared after commit [1](https://github.com/odoo/odoo/commit/2752ca733b4feda4ef16eef02fdaba1561ceb6b7), it introduced root-level check for mergeability. Desired behavior after PR is merged: - Only formattable inline tags (SPAN, FONT, B, STRONG, I, EM, U, S) are eligible for merging. task-4965381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where selecting certain dynamic colors for SVG icons in the website builder could make the icon disappear or show the wrong color preview. This helps users customize website visuals more reliably, especially when using themes and custom palette colors.
Original PR description
__Current behavior before commit:__ The color palette for SVG Dynamic Colors doesn't work properly. The color preview doesn't show the current color and some colors make the SVG disappear.…
__Current behavior before commit:__ The color palette for SVG Dynamic Colors doesn't work properly. The color preview doesn't show the current color and some colors make the SVG disappear. __Description of the fix:__ - The [`_update_svg_colors`] backend method only works with rgb, hex and the palette colors matching `/^o-color-[1-5]$/`. So all other custom CSS variables (e.g. `var(--white)`) are converted to hex notation in the SVG URL search params. - Furthermore, to show the correct color in the little color preview circle, [`getValue`] now always returns a normalized CSS color value. - The regex matching rgba color in [`convertCSSColorToRgba`] has been fixed to include alpha values that don't have the 0 before the decimals (e.g. `rgba(255, 255, 255, .5)`). __Steps to reproduce:__ 1. Open the website builder 2. Switch to "Artists" theme 2. Drop a Horizontal Attributes snippet 3. Click on one of the SVG icon => the color previews in Image > Dynamic Colors don't correspond to the SVG colors 4. Click on one of the color to open the palette 5. Choose one in the top row => the SVG disappears 6. Go in the "Custom" tab of the color palette => the current color is not the correct one 7. Choose one of the grey shade at the top => the SVG disappears [`_update_svg_colors`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/html_editor/controllers/main.py#L92 [`getValue`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/website/static/src/builder/plugins/dynamic_svg_option_plugin.js#L29 [`convertCSSColorToRgba`]: https://github.com/odoo/odoo/blob/64efa6b7dc7/addons/web/static/src/core/utils/colors.js#L218
This fixes an issue in the website editor where applying a dynamic theme color to certain SVG images could make the image disappear. Business users can now customize snippet images with brand or theme colors reliably while editing website pages.
Original PR description
Following the [refactor] of the html_builder we had an issue whenever we tried to apply a dynamic color. To reproduce the problem: - Open website and start editing - Drop a s_attributes_horizontal snippet - Click on any of its images - Click on the "Dynamic Colors" option - Apply a theme color (in the first line) -> Image dissapears because instead of the actual color it applies a variable i.e. o-color-1 [refactor]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
This fixes a timing issue in automated chat tests where pressing Enter after typing a command could behave inconsistently. The tests now use the send button instead, making validation more stable without changing the user-facing chat experience.
Original PR description
\* = crm_livechat, im_livechat Back-port of 3fc3e4fbbd846dc8f65938a0bfbddbebf2abc403 Enter after typing a command will either send the message when the suggestion list is not opened yet, or select the suggestion. This can either be fixed by waiting for the suggestion list to be opened, closing it, and then pressing enter, or by simply clicking on the send button which is what is done here as the way the message is sent is irrelevant for these tests. https://runbot.odoo.com/odoo/runbot.build.error/230977 Forward-Port-Of: odoo/odoo#225934 Forward-Port-Of: odoo/odoo#225874
This fix makes transparent grayscale options appear correctly when editing website snippets and choosing custom color filters. It restores missing color definitions so users can reliably select the intended transparent gray styles in the editor.
Original PR description
Following the [refactor] of the html_builder, [addition] of the transparent grayscale, and this [commit], we had an issue when the transparent grayscale wasn't displayed as needed because it wasn't…
Following the [refactor] of the html_builder, [addition] of the transparent grayscale, and this [commit], we had an issue when the transparent grayscale wasn't displayed as needed because it wasn't added to 'EDITOR_COLOR_CSS_VARIABLES', which later were used to save colors together with the theme color prefix, i.e., --hb-cp-'color'. Steps to see the issue: - Open website and start editing - Drop a s_cover snipper and click on it - Click on the "Filter" option and select "Custom" - Click on "Color Filter" and go to the "Custom" tab -> Transparent Grayscale isn't displayed correctly. This commit copies [1], which was lost in the refactor. [refactor]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 [addition]: https://github.com/odoo/odoo/commit/55c58bf45165e3a3eafcbaecc516e7c1d19809a6 [commit]: https://github.com/odoo/odoo/commit/eb12451a169c752034abb5d4aab9926c19067ebf [1]: https://github.com/odoo/odoo/commit/5490c126f42bd1729ba0d4b4103d7284ba7ab8c0
Fixes an issue where unbuilding a manufacturing order for non-storable finished products or by-products could create duplicate stock movement lines. This keeps unbuild records accurate and avoids misleading inventory or production history.
Original PR description
When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production. ** Steps to reproduce ** - Create an untracked product (is_storable = False).…
When creating a unbuild order for non storable product, it will generate two stock.move.line going form Stock>Production.
** Steps to reproduce **
- Create an untracked product (is_storable = False).
- Create a BOM (the components don't matter).
- Create a manufacturing order & produce it for the untracked product.
- Unbuild the manufacturing order.
- Manufacturing Order> Unbuilds>(Select the Unbuild (UB/...))>Product Moves
- Two move lines are created from stock to production for the untracked product when only one should have been created.
** Cause of the issue **
Clicking on unbuild, will launch a call of the action_unbuild method. During this call,
the moves of the unbuild for the final product of the MO are created and confirmed here:
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/mrp/models/mrp_unbuild.py#L181-L182
During this confirmation process and since the product is not storable, (hence move should by pass reservation) therse moves will be assigned and the related move line created:
https://github.com/odoo/odoo/blob/e4d9ef3f39bd62a8db6854270b4cf6a35936b8d4/addons/stock/models/stock_move.py#L1759-L1762
https://github.com/odoo/odoo/blob/7dd7351d492babdfb7c671960c5e90755fbc2233/addons/stock/models/stock_move.py#L1581-L1583
However, in the rest of the action_unbuild call, since we don't expect the move to be assigned by the action_confirm we create and associate manually a second move line to our unbuild move:
https://github.com/odoo/odoo/blob/de2216ae52cee40d0851b4b8c0b71cb7e1d5ec89/addons/mrp/models/mrp_unbuild.py#L196-L198
** Observation **
During this commit
https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-31912cb536cbf184f8f475ccdfb5e42c30796a3f0430eea35751519434a67ba8L156
An "if condition" was removed that allowed untracked product to skip the manual assignation ("consu" product are untracked), since they already been assigned during consume_move._action_confirm().
This fix reintroduce the condition, for all move with their quantity (1) updated.
Which resolve the issue for non stored product since their quantity is updated during _action_confirmation>_action_assign
(1) https://github.com/odoo/odoo/commit/7dda6bb92715ea25b2818a62fec5e646f3678b81#diff-55c6314416a6a400da6acd5018d161a55eeeb0e3008fec8828121e3dd12be0ebR325
opw-4830965
Forward-Port-Of: odoo/odoo#213305Invoices created for child contacts now use the parent company’s configured sending method, such as Peppol, instead of defaulting to email. This helps ensure invoices are sent through the expected channel when customers manage invoicing settings at the parent contact level.
Original PR description
**Steps to reproduce** - Have a partner with Invoice Sending configured 'by Peppol' - Create a child contact for that partner - Make 2 invoices for the child contact - Select both and click 'Send' **Issue** The system will try to send invoice by mail, even if Peppol is correctly setup This occurs because when retrieving the default sending method we only look at the partner of the move, that, being a child contact, does not have invoicing info opw-4925876 Forward-Port-Of: odoo/odoo#225725 Forward-Port-Of: odoo/odoo#225097
Point of Sale cash out receipts now print when using an ePos printer connected through the hardware proxy. This prevents confusing success messages when no receipt was actually printed, helping stores complete cash handling reliably.
Original PR description
When the printer comes form the hardware_proxy, the receipt was not printing for a cash out. Steps to reproduce: ------------------- * Connect an ePos printer * Open pos * Create and validate a cash out > Observation: Notification says 'Succesfully...' Console log says 'No printer device available...' Why the fix: ------------ Introduced by this pr: https://github.com/odoo/odoo/pull/209274 This protection wasn't working for our usecase where the device is set after this check in this call `this.printHtml(el, options)`. A hoot test will be added during fw-port in 18.3 opw-4841441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222155
Website snippet previews now show the Parallax label only when the snippet actually uses a parallax background. This prevents misleading labels in theme snippets and ensures custom snippets with parallax effects are clearly identified.
Original PR description
Steps to reproduce the issues: **Issue 1** - Enter "Website" edit mode. - Drag and drop a "Cover" snippet into the page. - Save the snippet as a custom snippet. - Click the "Custom" category. - Bug:…
Steps to reproduce the issues: **Issue 1** - Enter "Website" edit mode. - Drag and drop a "Cover" snippet into the page. - Save the snippet as a custom snippet. - Click the "Custom" category. - Bug: the "Parallax" label is not displayed on the snippet preview. **Issue 2** - Install the "Artists" theme. - Enter "Website" edit mode. - Click the "Intro" category. - Bug: The "Parallax" label is displayed on the "Cover" snippet preview even though it doesn't have a parallax effect. Commit [1] added a label on snippet previews to indicate if they are Carousel, Popup, Gallery, Tab, or Parallax. This label is linked directly to the snippet's original template. However, this does not work well for "Parallax" because it's an option that can be enabled or disabled. So it doesn't make sense to keep the label when the option is not active. This commit fixes that by checking the snippet structure to see if it contains a parallax on its background. [1]: https://github.com/odoo/odoo/commit/63cd0c6497c3c2e8482dc62b4359eb2431a75926 task-4926420 Forward-Port-Of: odoo/odoo#218863
This update corrects an internal automated test related to email server handling so it behaves properly when a required testing dependency is unavailable. It helps keep Odoo's quality checks reliable and reduces false failures during release validation.
Original PR description
Fine-tunning of e31ec012 Forward-Port-Of: odoo/odoo#224309
When receipt items are moved into a new wave transfer, their related quality checks are now moved or recreated on the correct transfer. This prevents users from missing required quality checks on the new transfer or processing them from the wrong receipt.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Enterprise: https://github.com/odoo/enterprise/pull/92951
opw-5009635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224947
Forward-Port-Of: odoo/odoo#223852This update prevents an error when refusing a job applicant using a refusal reason that has no email template. Recruitment users can now complete the refusal process reliably without encountering a traceback.
Original PR description
**Step to reproduce:** - install `hr_recruitment` - open recruitment -> refuse reason - from any record say rec1, remove its email template - from recruitment, open a job application - refuse it, a wizard opens for reason, select rec1 **Observation:** - we receive a traceback **Cause:** - there is oversight in `_compute_from_template_id` method - `wizard_field_name` is refrenced outside of its scope **Fix:** - fix the method, to correctly assign the template values to wizard opw-5031197 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where changing the scheduled date for one product line in a receipt could unintentionally update other product lines when delivery features were installed. This helps keep warehouse schedules accurate and avoids unexpected changes during receipt planning.
Original PR description
### Steps to reproduce: - Install stock_delivery - Create and confirm a receipt for 2 products: - 1 x P1 - 1 x P2 - Modify the scheduled date of P1 to the day before - Save the picking #### Expected…
### Steps to reproduce:
- Install stock_delivery
- Create and confirm a receipt for 2 products:
- 1 x P1
- 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking
#### Expected behavior:
The scheduled date of the picking is updated but not the one of the other move.
#### Current behavior:
The the move scheduled date is also updated.
### Cause of the issue:
Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901
### Note:
This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38
opw-5017423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#225197
Forward-Port-Of: odoo/odoo#224986IoT box actions now include a unique ID so repeated delivery attempts can be recognized and ignored. This prevents accidental duplicate operations such as double printing or duplicate blackbox registrations when a request times out and is retried through another connection.
Original PR description
Enterprise PR: odoo/enterprise#93985 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. task-5067737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225678
This fix prevents accounting reconciliation errors when a kit product is invoiced before its delivery is validated. It ensures stock and accounting entries are matched using the sold or purchased kit product, so businesses can complete deliveries and purchases involving kits without manual intervention.
Original PR description
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp} ### Steps to reporduced: - In the settings enable: Automatic Accounting - Create 3 storable product: - COMP1, cost 1 $ - COMP2, cost 2 $ -…
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp}
### Steps to reporduced:
- In the settings enable: Automatic Accounting
- Create 3 storable product:
- COMP1, cost 1 $
- COMP2, cost 2 $
- KIT with a kit bom using COMP1 and COMP2, cost 3 $
- Modify the product category of all three products to:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Create and confirm a sale order with 2 lines:
- 1 x KIT
- 1 x COMP2
- Create and confirm the associated invoive
- Try to validate the delivery
#### > UserError: You are trying to reconcile some entries that are already reconciled.
### Cause of the issue:
Validating the delivery will create stock valuation layers related to the associated stock moves — one for COMP1 and two for COMP2 — and then attempt to validate the corresponding accounting entries: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_move.py#L283-L291
However, during this call, the SVLs are grouped by product_id: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L88-L93
As a result, the first time we enter the loop, the accounting entries related to COMP01 will not be reconciled by the
`_stock_account_anglo_saxon_reconcile_valuation` call. This is because we restrict this call using the product COMP01. Therefore, we will not find the invoice needed to reconcile the outgoing moves here: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/account_move.py#L217-L219 (This happens because the related line of the invoice actually refers to the kit product, as the AMLs were not exploded like the stock moves.)
Now, the issue is that, since the AMLs were not reconciled, they will be added to the pool of lines to be reconciled later: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L92-L100
However, the second time we enter the loop — for COMP02 — since COMP02 was sold by itself, there will be an account move line referring to this product on the invoice. The `_stock_account_anglo_saxon_reconcile_valuation` call, now restricted to COMP02, will therefore reconcile the AMLs for both COMP02 and COMP01 related to the kits (as it successfully finds the invoice to reconcile all outgoing moves). This is problematic because the AML related to COMP01 has now been reconciled, despite already having been added to the set of moves to be reconciled. This will raise an error during the second reconciliation attempt: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/account/models/account_move_line.py#L2379-L2380
### Fix:
In the case of kit products, the account move lines of the invoice refer to a different product than the stock valuation layers (because the stock move was exploded but not the AMLs). Therefore, it is important to refer to the kit product during the reconciliation process.
We achieve this by grouping the SVLs using the product of their associated SOL or POL. Unfortunately, we cannot rely on the product from the BoM related to the stock move of the SVL, as kits can be nested within one another. In such cases, the invoice related to the SO or the bill related to the PO would not refer to the intermediate kit we would found that way.
opw-4864925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#224956
Forward-Port-Of: odoo/odoo#221337Imported French FEC accounting entries are now included when users open a sales journal from the accounting dashboard. This ensures imported sales-related records are visible in the expected journal view, reducing confusion and helping teams review imported accounts more reliably.
Original PR description
**PROBLEM** When importing a FEC files, moves are created with the `move_type` `entry`. They don't appear in the action of the journal of type `sale` when clicking on the dashboard. **STEP TO REPRODUCE** 1. on a local database install `l10n_fr_fec_import` (you need to import a FEC file given by our client, dont do it on the runbot please !) 2. select the french demo company 3. import the FEC file (accounting/settings/import a file) (for file, see [ticket](https://www.odoo.com/odoo/project/49/tasks/4848763) ) 4. goes in the dashboard, and click on the `Ventes Marchandises` journal. 5. notice the entries does not appear in the action. **CAUSE** When importing a FEC file, all moves are created with the `entry`. The domain for `sale` journal doesn't include the move of type `entry`. **FIX** Adding `entry` in the `sale` journal domain. opw-4848763 Forward-Port-Of: odoo/odoo#222208
Duplicated Team Basic website blocks now keep images editable, so users can select those images and adjust their options as expected. This prevents a frustrating page editing issue when reusing team sections.
Original PR description
[FIX] html_builder, *: enable image options on duplicated team snippet *: html_editor Steps to reproduce the problem: - Drop the "Team Basic" snippet. - Duplicate it. -> When you click on an image of the duplicated block, the image is not selected and you can not change the options related to it. The problem is that the `o_editable_media` class does not appear on the images of the duplicated snippet as it is a system class. This commit removes the `o_editable_media` class from the system classes. Indeed, it was added by [1] to avoid the closest savable to be marked as dirty when this class was added. However, this class is added during the `normalize` and since [2], the mutations done at the `normalize` do not trigger the adding of the `o_dirty` class anymore. [1]: https://github.com/odoo/odoo/commit/c20dfb73528d60a079d73564504646fe7d1d4272 [2]: https://github.com/odoo/odoo/commit/7c5cdb6d70eea29dec4ba126e62eeb93c6e6eeb2 Related to task-4367641
Bank reconciliation now applies the expected analytic distribution to early payment discount lines, matching the behavior of manually registered payments. This helps ensure discount-related accounting entries are categorized correctly for reporting and analysis.
Original PR description
# Steps to reproduce: - Configure an early discount payment term (e.g., 2/7 Net 30). - Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the…
# Steps to reproduce: - Configure an early discount payment term (e.g., 2/7 Net 30). - Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the BE fiscal position). - Create an invoice using the early discount payment term. - On bank reconciliation, register the transaction taking into account the early payment discount (e.g., 98% of the invoice amount_total). On the third line with account 657000, corresponding to the early discount payment, the analytic distribution model does not apply. In contrast, when manually registering a payment for the invoice, the analytic is correctly applied. When the bank reconciliation lines are created, _lines_check_apply_early_payment_discount gets its values for the early payment lines from _get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line, which does not check if there is an analytic distribution model. enterprise pr: https://github.com/odoo/enterprise/pull/90641 opw-4868986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221785 Forward-Port-Of: odoo/odoo#217933
Event, session, and sponsor searches now work correctly when a website is viewed in languages other than English. This prevents translated labels from breaking search filters, helping visitors find relevant event content regardless of their selected language.
Original PR description
**Issue:** - After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language selected except `en_US`.…
**Issue:** - After https://github.com/odoo/odoo/commit/777cb220259e1c1529b960761a6f59ec6115038e we are not able to search for event/track/sponser when we have other language selected except `en_US`. - This is because of how `search_type` attribute is set in related templates. - currently it gets translated as according to website's language, for e.g when website's language is `Spanish (AR) / Español (AR)` 'events' get translated to 'eventos' and 'track' get translated to 'sesión' - hence the parameter for search get altered, failing the search. https://github.com/odoo/odoo/blob/ac5ea3cbd075db650c8e538d59e24657a0f04bb9/addons/website/static/src/snippets/s_searchbar/000.js#L118-L121 **Step to reproduce:** - Add another language except en_US, say ,spanish - install website_event - open events from website and switch language to spanish - search for event **Observation:** - No search result **Fix:** - set the search_type attribute correctly, i.e using `t-valuef` opw-4972519 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226084 Forward-Port-Of: odoo/odoo#221877
The web interface now handles cases where custom app icons are too large to save in the browser. This prevents users from seeing errors when navigating menus after adding large image icons to custom applications.
Original PR description
Before this commit, if a user uses a large image as an icon for a custom application, an error could be triggered due to the size limit in localStorage. Forward-Port-Of: odoo/odoo#226105
The Print button now produces a Purchase Order document once an order is confirmed, instead of incorrectly printing a Request for Quotation. This reduces user confusion and helps ensure buyers share the right document at the right stage of the purchasing process.
Original PR description
Before this commit: ------------------------- - The 'Print' button in the Purchase Order form always triggered the RFQ report, regardless of the order state. - This caused confusion for users…
Before this commit: ------------------------- - The 'Print' button in the Purchase Order form always triggered the RFQ report, regardless of the order state. - This caused confusion for users expecting the Purchase Order report when the order was already confirmed. Steps to reproduce: ------------------------- 1. Install 'purhcase' module. 2. Confirm a purchase order (move it to the 'Purchase Order' state). 3. Click on 'Print' button . 4. Notice that the RFQ report is printed instead of the PO report. Cause of the issue ------------------------- - The print button was hardcoded to always prints the RFQ report—even for confirmed purchase orders. After this commit: ----------------------- - The system now prints the Purchase Order report when the order is confirmed. - The Print button behavior dynamically changes based on the order state - This improves user experience by ensuring the correct document is printed according to the current state of the order. Task Id: 4905350 Forward-Port-Of: odoo/odoo#221148
Belgian payroll work entry UCM codes now preserve spaces when needed to meet the required three-character format. This prevents valid UCM codes such as "PR " from being shortened incorrectly, helping payroll configuration stay compliant with UCM specifications.
Original PR description
#### Issue: - UCM work entry code should be 3 characters long and allow spaces to get this length #### Step to reproduce: - In a Belgian company - Go to Payroll > Settings > Work Entry Types > New - Add a name - Add a Payroll Code - In the `Country` field fill Belgium - In the field `UCM Code` enter "PR " - Select another field - Select `UCM Code` again #### Current behavior: - The field `UCM Code` was updated to "PR" #### Expected behavior: - The field should stay to "PR " #### Solution: - Don't trim the field and add a spaces if needed opw-5014372 Forward-Port-Of: odoo/enterprise#92838
The Belgian salary configurator now prevents employees from combining private bike reimbursement with fuel card benefits when the private bike amount is above zero. This keeps salary package choices consistent by automatically clearing and disabling fuel card fields in that situation.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#94063 Forward-Port-Of: odoo/enterprise#93884
This fix ensures that when receipt items are moved into a new wave transfer, the related quality checks are moved or recreated on the correct transfer. Users will see quality check actions on the right receipt, reducing the risk of processing checks against the wrong operation.
Original PR description
*{quality_control,stock}_picking_batch ### Steps to reproduce: - Got to Quality > Quality control > Control Point - Create a quality control point: - Operation: receipt - Control per quantity or…
*{quality_control,stock}_picking_batch
### Steps to reproduce:
- Got to Quality > Quality control > Control Point
- Create a quality control point:
- Operation: receipt
- Control per quantity or product
- Create a and confirm a receipt transfer with 2 products
- Go to the receipt list view > select your receipt > Wheel action > Add to wave > Add to a new wave > Add only one of the move line to the wave
#### > A new picking is created and the move line reassigned to it but the related quality check picking_id is not updated.
> In particular, there is no "quality check" button on the new picking and the "quality check" button of the first picking allows you to process a QC related to the wave transfer.
### Cause of the issue:
While the move lines or move are can be moved to a new picking during the `_add_to_wave` call:
https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/stock_picking_batch/models/stock_move_line.py#L69-L90 Nothing is done with respect to the quality check which pciking_id field is not computed:
https://github.com/odoo/enterprise/blob/d73f7ef6fe61ccddbe1fe4e32c1670611ba3c5d2/quality/models/quality.py#L185
### Fix:
While the quality check measured on move_line are linked to a move line, the quality checks measured on products and operation are not. For the first kind, we rely on an override of the write method of stock move lines to reassign the check to the apporpiate picking. For the other kinds, we add a post batch hook to unlink the obsolete checks and recreate the appropiate one. Note that since operation and product types are created during the action confirm of moves and since certain moves will be created and auto confirm during the new picking creation here: https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock_picking_batch/models/stock_move_line.py#L90 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L857 https://github.com/odoo/odoo/blob/73fd3af560c967f41339bfc4c71a51dc5baba4a8/addons/stock/models/stock_picking.py#L1263-L1267 https://github.com/odoo/enterprise/blob/b99d7073a34b24d4d3b863278e68f292fdd3c0b0/quality_control/models/stock_move.py#L12-L15 we rely on the `extra_move_mode` to avoid quality check creation during this step (as they will be created in the hook).
Community: https://github.com/odoo/odoo/pull/223852
opw-5009635
Forward-Port-Of: odoo/enterprise#93605
Forward-Port-Of: odoo/enterprise#92951This fix prevents IoT Box actions from being carried out twice when a request times out and is retried through a fallback connection. It reduces the risk of duplicate prints, registrations, or other repeated device actions, improving reliability for users relying on IoT workflows.
Original PR description
Community PR: odoo/odoo#225678 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. This PR handles the client side code, which just involves adding the new `action_unique_id` key to all our actions that are using fallbacks. task-5067737 Forward-Port-Of: odoo/enterprise#93985
The Peru electronic invoicing module can now be installed on large databases without exhausting memory. The update also prevents an installation error when some tax groups are missing, making setup and upgrades more reliable for affected customers.
Original PR description
### [PERF] l10n_pe_edi: Avoid OOM during installation ### Description: Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens…
### [PERF] l10n_pe_edi: Avoid OOM during installation ### Description: Installing `l10n_pe_edi` on large databases with many moves and move lines could cause out-of-memory (OOM) errors. This happens because several stored fields need to be computed at installation. ### Fix: This fix adds the columns via SQL, preventing Odoo from computing and populating the field for all existing records. This reduces memory usage and avoids installation failures. ____ ### [FIX] l10n_pe_edi: Fix error during post-init hook ### Description: During installation, the `l10n_pe_edi` module's post-init hook attempts to update tax groups, setting the new `l10n_pe_edi_code` field. This can cause an error if a tax group doesn't exist and needs to be created, because the name field is missing in the list of values given to the `_load_records` function. ### Fix: This fix filters the tax groups to only update existing ones. This prevents `_load_records` from trying to create new groups, which avoids the installation error. ___ ### Reference: opw-4982181 Forward-Port-Of: odoo/enterprise#91997
After sending a document for signature from a record's chatter, users are now taken back to the original record instead of staying on the document view. This keeps the workflow focused and reduces extra navigation for users handling signature requests.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Open the chatter of any app record. - Open PDF uploaded in chatter. - Click on sign button for signing. - Send document for signing by keeping signer other than yourself. Before: - After sending for sign, the user stays on the document view instead of returning to the originating record. After: - After sending for sign, the user is redirected back to the originating record linked to the signature request. impact: - Improves user workflow by keeping them on the record they were working on. - Provides a smoother navigation experience. task-5059410
Fixes a timing issue that could affect sending messages with the Command + Enter shortcut in enterprise messaging and live chat areas. This helps prevent failed or inconsistent message submission, improving reliability for users communicating through Discuss and helpdesk live chat.
Original PR description
\* = test_discuss_full_enterprise, website_helpdesk_livechat Back-port of 14b31a3631a97dd61ebd662fb768485e5a509c2c Enterprise counter-part. https://runbot.odoo.com/odoo/runbot.build.error/230977 Forward-Port-Of: odoo/enterprise#94115 Forward-Port-Of: odoo/enterprise#94078
This fix prevents Uruguayan electronic invoices from failing when an invoice line has limited information, such as only an account and no product. If no line name is available, the system now safely uses a placeholder so the CFE document can still be created.
Original PR description
This pull request makes a minor adjustment to the logic for extracting item names and descriptions in the `_l10n_uy_edi_get_line_nom_and_desc` method. The change ensures that the presence of `aml.name` (the line description) is checked directly, rather than relying on the truthiness of the entire `aml` object. Before this PR, if the aml of an invoice only have the `account_id` field filled and no `product_id`, the `_l10n_uy_edi_get_line_nom_and_desc` will raise an error message like `TypeError: 'bool' object is not subscriptable` when trying to create de CFE document. <img width="1254" height="828" alt="image" src="https://github.com/user-attachments/assets/eaadad4c-46c3-4e3b-be52-9fcd146f2c22" /> <img width="1526" height="795" alt="image" src="https://github.com/user-attachments/assets/1b831f41-9774-4ed5-9a9d-9777ee0633e9" /> With this fix, we ensure there is a name to grab or the '-' will be send instead. Forward-Port-Of: odoo/enterprise#93838
A test was added to ensure early payment discount lines created during bank reconciliation receive the correct analytic distribution. This helps keep accounting reports consistent whether payments are registered manually or through bank reconciliation.
Original PR description
This commit adds a test for the following issue: - Configure an early discount payment term (e.g., 2/7 Net 30). - Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the BE fiscal position). - Create an invoice using the early discount payment term. - On bank reconciliation, register the transaction taking into account the early payment discount (e.g., 98% of the invoice amount_total). On the third line with account 657000, corresponding to the early discount payment, the analytic distribution model does not apply. In contrast, when manually registering a payment for the invoice, the analytic is correctly applied. community pr: https://github.com/odoo/odoo/pull/217933 opw-4868986 Forward-Port-Of: odoo/enterprise#91651 Forward-Port-Of: odoo/enterprise#90641
The Documents app kanban view no longer shows an unnecessary second scrollbar. This makes browsing documents cleaner and reduces confusion for users navigating the page.
Original PR description
This commit fix the useless double scroll bar in kanban view. Task-4844661 Forward-Port-Of: odoo/enterprise#90548
Fixed an issue where opening an embedded list view from a Knowledge article could accidentally save hidden view settings and later cause an error when editing the article. This keeps Knowledge articles editable after users navigate into embedded views and return.
Original PR description
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical…
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical ============= When we open a view from an embedded view in the article, we add `orderBy` from the action context to the action props if it exists. As the action prop is initialized and assigned directly from `embeddedState.additionalViewProps` without copying, it mutates the original object, changing the `data-embedded-props` attribute in the DOM and marking the body of the article as unsaved from `StateManager.changeState`. The action continues, and the action service commits those unsaved changes to the article. Once it is saved and the action is executed, when we get back to the article and click on edit, we check for `additionalViewProps` to be undefined/empty for all other views except calendar. As the DOM already has saved data in attributes, we get `orderBy` in `additionalViewProps`, and thus a manual error is thrown in the `editView` function. After this commit =============== Clone `additionalViewProps` when preparing the view action props. Task-4921282 Forward-Port-Of: odoo/enterprise#91113
Fixes an issue where changing a dashboard's publish status could be accidentally undone by clicking elsewhere in the header. The publish checkbox now behaves consistently, reducing confusion when editors update dashboard visibility.
Original PR description
**Steps to reproduce:** - Open a dashboard in edit mode. - Click the “Publish” toggle to change its state. - Click elsewhere on the header (outside the toggle). → The publish state flips back unexpectedly. **Before this PR:** The wrapper container (.o_sp_publish_dashboard) had a click handler, causing clicks on the header to re-toggle the publish state. The CheckBox was rendered with a no-op onChange, so both elements competed for control. **After this PR:** Interaction is handled exclusively by the CheckBox component. toggleDashboardPublished is bound directly to its onChange. Clicking the label text now correctly toggles the checkbox and publish state. Container clicks outside the checkbox no longer affect the state. Task: [5062368](https://www.odoo.com/odoo/project/2328/tasks/5062368) Forward-Port-Of: odoo/enterprise#94061
DHL and USPS shipping integrations now correctly retrieve package details from sales orders. This helps ensure shipping information is accurate before fulfillment, reducing carrier errors and manual corrections.
Original PR description
This commit fixes the same issue in #89771, but for sale orders instead of pickings. opw-4979982 Forward-Port-Of: odoo/enterprise#94186
Code cleanup and technical improvements
This update prepares customer follow-up reports for easier customization of due and overdue invoice lines. It helps businesses tailor what customers see on payment reminder reports without changing the standard report flow.
Original PR description
The goal with these hooks is to allow customization of overdue and due lines that are going to be printed on the followup report to be communicated to the customer. Forward-Port-Of: odoo/enterprise#93438