Daily updates from Odoo
Friday, October 10, 2025
43 changes · saas-18.4
Resolved issues and error corrections
The AI assistant now includes planned chatter activities alongside existing conversation messages when generating content. This helps produce responses that better reflect upcoming tasks and customer context.
Original PR description
Append any planned activities to the chatter messages to be sent as a part of the prompt's context with the rest of the messages. task-id-5079055 Forward-Port-Of: odoo/enterprise#95764
The time off request summary card has been adjusted so leave measured in hours displays clearly without overly long text. This improves readability for employees and managers reviewing time off requests.
Original PR description
On a time off request, there is a summary on the side. Problem: if we have time off in hours, the display is not adapted and the text is too long. This commit fixes the issue to display the hours correctly. task-5092855 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#227631
This fix prevents Chrome on iOS from automatically changing certain text on Odoo pages in a way that could break the interface. It helps users on affected iPhones and iPads avoid rendering problems when using Odoo in Chrome.
Original PR description
Chrome iOS wraps some text nodes (like measures, email...) with a `<chrome_annotation>` tag, which breaks OWL rendering. This commit works around it by adding the (undocumented) `<meta name="chrome"…
Chrome iOS wraps some text nodes (like measures, email...) with a `<chrome_annotation>` tag, which breaks OWL rendering. This commit works around it by adding the (undocumented) `<meta name="chrome" content="nointentdetection">` tag to disable this Chrome behavior. The tag has to be set before the onDOMContentLoaded event to be taken into account. Note: Looks like this behavior was present in Chrome iOS 127 and disabled afterward (because it already had issues) but it appeared again in version 140-141. References: - https://issues.chromium.org/issues/353650041 - https://issues.chromium.org/issues/388718411 - https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags - https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile - https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an - https://github.com/solidjs/solid/issues/2235 opw-4969197 Forward-Port-Of: odoo/odoo#230081
Adyen checkout now sends the extra order details required by certain payment methods, such as Klarna, including country information and line items. This helps customers complete payments that previously could fail because required information was missing.
Original PR description
Some payment methods eg. Klarna require 'country code' and 'line items' in order to process the transaction. opw-5077617 Forward-Port-Of: odoo/odoo#230292
This fixes how tables copied into the HTML editor are handled so they automatically receive the standard Odoo table styling. Users get more consistent, properly bordered tables after pasting content, reducing manual formatting work.
Original PR description
### Purpose of this PR: - Ensure that pasted table elements get the standard classes: `table, table-bordered, and o_table.` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230517 Forward-Port-Of: odoo/odoo#230208
Emails sent from Odoo could fail when they included an attached email file containing accented or other non-English characters. This fix makes Odoo handle those attached email files correctly, so messages can be sent reliably without serialization errors.
Original PR description
The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with…
The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized ### Steps to reproduce 1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body. The sending of that email will fail with a `UnicodeEncodeError` error ### Cause Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment. While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process. ### Fix Instead of attaching the raw bytes, we now: * Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object. * Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically. opw-4655868 Forward-Port-Of: odoo/odoo#230384 Forward-Port-Of: odoo/odoo#223790
The Attendance app now correctly groups records by department after correcting a typo. This helps users get accurate department-based attendance views and reports without workarounds.
Original PR description
- Fixed typo in groupby for 'department' task-id - 5109185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228334
Creating a goal from an employee appraisal now assigns the goal to the employee being appraised, rather than the current user. Creating a goal directly from the Goals menu no longer pre-fills employee or manager fields, reducing incorrect goal assignments.
Original PR description
If you go on _appraisals -> any employee -> goals smart button -> new_, it will populate the employee field with the current user. Instead, the field should be filled by the appraisal's user. If the goal is created from the "Goals" menu item directly, then no user / manager should be put by default in the goal's fields. I changed the field's default value to use the employee already passed in the context. I also added some tests to make sure the bug doesn't happen again. task-5048292 Forward-Port-Of: odoo/enterprise#93522
Subcontracted manufacturing orders can no longer be unbuilt, preventing incorrect accounting entries from being generated. This helps keep inventory valuation and financial records accurate for subcontracting workflows.
Original PR description
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost…
**Problem:** unbuilding a Manufactring order created through a subcontracting process gives the wrong account move lines **Steps to reproduce:** - create a storable product (the comp) and set a cost - create a storable product (the final product), set a cost and set a vendor - for the final product set the category as avco and automated - for the final product create a bill of materials subcontracted and set the same vendor - for the components add the comp for a quantity of 1 - create a Purchase order for the final product and the same vendor and confirm - validate the receipt - From the receipt click on the valuation smart button and click on the book widget of the line of the final product - notice how there is 3 journal items line including one crediting "stock interim (Received)" - unarchive the operation type "subcontracting" - open Manufacturing/Manufacturing Orders, delete the "to do" filter and search for a Manufacturing order with your final product - unbuild it - Open accounting/journal entries and select the journal entry for the unbuild **Current behavior:** There is only two account lines. There is no line balancing the "Stock Interim" line of the manufacturing order. **Cause of the issue:** The override of _generate_valuation_lines_data in mrp_subcontracted_account adds the stock interim line on the manufacturing order. However when unbuilding, the qty is negative so we exit the function https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20 **fix** Because subcontracted Manufacturing orders are not meant to be unbuilt, we prevent it opw-4998137 Forward-Port-Of: odoo/odoo#230062
Quality checks on serial-numbered products now correctly keep a failed result when launched directly from a receipt. This prevents failed items from being incorrectly marked as passed, improving inventory quality control accuracy.
Original PR description
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control…
Serial number tracked product are marked as pass even when they fail a move_line type of check. ### Steps to reproduce: * Create a product tracked by serial number * For this product create a control point: - Control per quantity - Operations : Receipts * Create a receipt for this product * Mark the receipt as Todo * Start the Quality check from the receipt, without using the smart button. * Fail the Quality check * The Quality check still passes ### Issue: When validating a quality check and it fails: https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity opw-5015266 Forward-Port-Of: odoo/enterprise#92966
This fix prevents Odoo from recreating the default employee administrator record during updates when companies have already replaced it with their own setup. This helps avoid unwanted sample-like employee records reappearing in HR data after upgrades.
Original PR description
The `employee_admin` is a default admin option. Later when clients set up their work flow they set up their own admin employee. This record is not present, and it doesn't make sense recreate it with every update. 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#230250 Forward-Port-Of: odoo/odoo#228117
This update corrects how table cells are selected in the HTML editor. A single cell is now selected only when all of its content is selected, preventing confusing or accidental selections while editing text in tables.
Original PR description
Current behavior before PR: - Create an m x n table. - Write some text in a cell. - Put cursor at the end of text. - Try to select cell by moving mouse rightwards. Notice that the cell is selected although the cell content is not fully selected. Desired behavior after PR: This PR backports commit [1] to ensure that single cell is selected only if the cell content is fully selected. [1]: https://github.com/odoo/odoo/commit/09d369e118f622f30149f46702f58c656a3cee04 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230133 Forward-Port-Of: odoo/odoo#230071
Videos added inside certain website layout blocks now expand to the full width available instead of appearing unexpectedly small. This improves the editing and viewing experience for website pages using Masonry or Quadrant-style sections.
Original PR description
To reproduce: ============= 1- In Website edit mode, drop the "Masonry" snippet. 2- Add a video in one of the text blocks. -> It will appear smaller than expected, with no way to make it larger Why: ==== The child iframe already had width: 100%, but it can only stretch to 100% of its parent container. If the parent container (.media_iframe_video) doesn't have an explicit width, it defaults to its minimum content size. This issue happens specifically in blocks where the columns are display: flex. As a result, the iframe ends up being too narrow despite having width: 100%. Solution: ========= By adding width: 100% to the container itself, it now fills the grid cell, and the iframe inside fills the container. opw-5104640 Forward-Port-Of: odoo/odoo#229001
Time off warning messages now appear in the right place with consistent spacing. This prevents the India-specific sandwich leave alert from appearing collapsed when creating a new time off request, making important guidance easier to notice.
Original PR description
Issue: The sandwich leave alert for l10n India was incorrectly shown folded when creating a new time off entry for Indian companies. Additionally, the leave_type_increases_duration alert lacked proper top margin, causing inconsistent spacing. Steps to Reproduce: - For the sandwich alert: When shown, it appears folded automatically when creating a new time off entry (only for Indian companies). - For leave_type_increases_duration: When displayed, it lacks top margin. Fixes: - Moved the sandwich leave alert to the header alongside other alerts for consistency. - Adapted margins for all alerts. Task ID: 5071899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226229
The manufacturing Bill of Materials overview no longer fails when the system cannot schedule the maximum producible quantity within its planning horizon. Instead, it retries using the requested quantity, helping users view production details without being blocked by an availability error.
Original PR description
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3.…
### Steps to reproduce: 1. Install mrp + purchase 2. Create a new product (A) 1. Add the Buy route on the product 2. Add a vendor line on the Purchase tab 3. Set the quantity on hands to 2000 3. Create a second product (B) with manufacturing route 4. Create a BoM for this product (B) 1. Add the product (A) as the component with 1 quantity 2. Create a new operation with a duration of 600:00 5. On the product B's page, click Replenish 1. Put 10 quantities to replenish 2. Select the manufacturing route and confirm 6. Go to the BoM and open the BoM overview 7. 'Impossible to plan. Please check the workcenter availabilities.' https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715 ### Before this commit: When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed. ### After this commit: If the quantity producible cannot be planned, we retry automatically with the requested quantity. opw-5031724 Forward-Port-Of: odoo/odoo#229745 Forward-Port-Of: odoo/odoo#227433
This fix prevents the HTML editor from creating invalid page structure when users change the style of text inside certain inline elements displayed as blocks. It helps preserve the intended content layout and avoids unexpected browser rendering issues.
Original PR description
Before this commit we would insert a block inside of a phrasing content if it's displayed as a block and we change its font style. For example, if we tried to modify text inside of a `<small>` that has `display: block` style, it would insert a new block inside of it. Steps to see the issue: - Have an open editor with `<small>Text</small>` content, that has `display: block` style - Select "Text" and change the font style to paragraph => It will be `<small><p>Text</p></small>` which is not valid HTML, and it will be parsed by a browser as `<small></small><p>Text</p>`, which is not the expected behavior. task-5123274 Forward-Port-Of: odoo/odoo#229043
This fix ensures Indian HR leave rules calculate time off correctly when holidays or weekends surround a leave period. It also makes half-day leave requests count as 0.5 day instead of a full day, improving payroll and absence tracking accuracy.
Original PR description
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off >…
**Steps to reproduce:** - Install l10n_in and l10n_in_hr_holidays module - Time off > configuration > Public holidays - Create a public holiday for Independence Day (15/08/2025) - Go to Time off > configuration > 'Time off Types', - Create a Time off type with - 'Sandwich leave' ticked and `Take Time Off in` to half a day - Go to Time off > Management > Time off - Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 - Case 2: Create a paid time off with any date and mark it as a half-day **Observation:** - Case 1: You will see Duration 3 days with the sandwich leave policy. - Case 2: Half-day leave shows 1 day instead of 0.5 **Root Cause:** - Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46 - Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not. https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19 **Solution:** - Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found. - Case 2: Fixed duration calculation to add 0.5 for half-day leaves. opw-5025766 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226883
This fix restores Indian accounting localization updates that were missed during a previous forward-port. It corrects tax naming and chart of accounts data so businesses using the India localization see the intended accounting configuration.
Original PR description
During the following [fw-port](https://github.com/odoo/odoo/pull/229757/) and resolving conflicts few changes such as Renaming of taxes and change of CoA was missed out in this commit we resolve the issue and add the missing changes that were unintentially missout during fw-port --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230787
This fix prevents an error page when someone opens a course embed link that points to a course category instead of an individual lesson. Users are now redirected to the course homepage, keeping the learning experience stable and avoiding a confusing crash.
Original PR description
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the…
When users try to access a `slide ID` that is not included in `channel_slides_ids`, a traceback occurs. Steps to reproduce: --- - Install `website_slides` module - Go to the Website and click on the `Courses` menu. - Then go to `/slides/embed/<int:slide_id>` route. (http://localhost:8069/slides/embed/7) - The error will occur. Traceback: --- `ValueError: 7 is not in list` At [1], `slide_content_ids` contains the IDs of `channel content`. However, we are trying to access a slide from the `channel category` in URL. As a result, at [2], when attempting to find the index of the slide in `slide_content_ids`, an error occurs because the slide ID actually belongs to `slide_category_ids` and is not present in `slide_content_ids`. Solution: --- Added a special case for category slides — if the slide is a category, redirect to the channel homepage. [1]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L120 [2]- https://github.com/odoo/odoo/blob/482bb19e103de9ddbe1b1942b94b33d3da38889b/addons/website_slides/controllers/main.py#L121 sentry-6572999628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225374
This fix makes an automated barcode workflow test wait for the right screen state before validating an operation. It reduces random test failures, helping keep inventory barcode updates more stable and predictable for future releases.
Original PR description
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; -…
Sometime, the test `test_scrap_change_source_location` could fail randomly. The issue happens in last few steps of the tour. What we do is: - We edit a move line lot in the form view; - We save it; - We validate the operation. The validation is done by a barcode scan (`OBTVALI`) but since [1](https://github.com/odoo-dev/enterprise/commit/b3a855a870d1861515abaff8683081a39f95558f), barcodes scanned when the user is somewhere else than in the barcode lines view are skipped. With a little bit of bad luck, the tour scans `OBTVALI` while the save from the form view is not finished yet and thus, the scanned barcode is ignored. To reproduce that, run the test `test_scrap_change_source_location` locally in debug mode and add a throttling (eg.: Fast 4G) before to run the tour. To solve the issue, finetune the `validateBarcodeOperation` default trigger, so the error won't happen in this tour and other similar contexts. Runbot build error: [232331](https://runbot.odoo.com/odoo/runbot.build.error/232331) Forward-Port-Of: odoo/enterprise#96542
The bank reconciliation widget now preserves existing invoice or bill matches when users choose a write-off account that has a default tax. This prevents matched transactions from disappearing and helps accounting teams complete reconciliations without repeating work.
Original PR description
In the Bank reconciliation widget, users can click a button to set the account to write off the remaining balance. However, if the chosen account has a default tax set, the widget will lose any existing matches with invoices. Steps to reproduce: - Have an account with a default tax - Create a bill with a total - Create a bank statement for a greater amount - Open the bank reconciliation widget - In the created statement, first add the bill, then click 'Set Account,' and choose the account with tax Issue: Bill matching will be lost. This occurs because we remove and recreate the matching line, but we don't keep the line to be reconciled. opw-5002624 Forward-Port-Of: odoo/enterprise#96006
Releasing an unused restaurant table no longer leaves behind a pointless draft order. This keeps POS order records cleaner while still cancelling kitchen tickets correctly when an order has already been sent to the kitchen.
Original PR description
Steps to reproduce: ------------------------- - Install POS restaurant. - Open any table to order. - Release the table. Issue: ------- - A draft order is created without purpose or use. Cause: --------- - On releasing the table we were not deleting the order, we were just cancelling the order even if it's not useful. Fix: ----- - We have called a proper function to manage the conditions like - If the order is sent to kitchen it will cancel the kitchen ticket to avoid inaccuracy kitchen side and already recorded on server so it will be cancelled and if the order was not sent to kitchen than there is no need of the order so will be removed totally. - We have corrected condition to send order in kitchen as `last_order_preparation_change` will always have some keys with blank values but we need to send data based on the lines changed in lopc. task: 4774814 Forward-Port-Of: odoo/odoo#209209
The Documents app no longer shows an unused tooltip field on document tags, reducing confusion for users managing tag settings. The field remains safely in the system for compatibility but is marked as deprecated until it can be fully removed in a future version.
Original PR description
The 'tooltip' field was introduced on document tags categories, but after couple of refactors it ended up unused on document tag. As we cannot remove fields from the data model in stable, this commit removes tooltip from the view and marks it as deprecated in the code. opw-4567814 ## Stems from https://github.com/odoo/odoo/pull/210147 https://github.com/odoo/enterprise/pull/79496 # Merge plan - hide `tooltip` in stable - remove `tooltip` in master Forward-Port-Of: odoo/enterprise#86504
Inventory deliveries now correctly clear the picked status when a completed package move is undone. This prevents deliveries from getting stuck in a waiting state and preserves picked status when users manually enter quantities after no stock was initially available.
Original PR description
### Issue: To reproduce the bug: 1. Activate `Packages` settings in Inventory: 2. Activate `Move entire packages` on picking type `delivery orders` 3. Create new product `Test move package` 4. Update…
### Issue:
To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.
The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.
### Cause of issue
Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.
### Fix:
In the fix, picked is set to False when there no
`move_line_ids`
### Issue 2
This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,
### Cause of issue 2
To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
move.picked = False
+ else:
move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.
After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.
### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
opw-4964561
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222034This fix prevents sales orders and invoices from crashing when they use a contact that has no name. Sale warning messages now handle unnamed partners safely, allowing users to continue creating documents without interruption.
Original PR description
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from…
When creating a Sale Order or Invoice for a partner without a name, a traceback occurs. Steps to reproduce the error: - Install ``sale_management`` with demo data - Enable ``Sale Warnings`` from settings - Open ``Azure Interior`` Contact > In Contact, Add Contact > Type: invoice > Save & close - Create a sale order with the newly created partner AND - Create an invoice with the newly created partner Traceback: ``TypeError: unsupported operand type(s) for +: 'bool' and 'str'`` https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/sale_order.py#L822 https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/sale/models/account_move.py#L59 Here, ``partner_id.name`` is ``False``, which leads to string concatenation with a boolean in sale warning messages and results in the above traceback. sentry-6912482256 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229529
This fixes how certain Spanish 0% service sales taxes are classified in VAT report Modelo 303. It prevents these services from being reported as exports and corrects the refund sign, improving tax reporting accuracy for Spanish companies.
Original PR description
The s_iva_e tax (IVA 0% Extracomunitaria (Servicios)) is configured as no_sujeto_loc, but is reported as "Exportacion" in modelo 303. There might have been the idea that we need a tax for services that are just a complement to some goods, but this tax is not used that way in practice. So, it is better to treat it as a duplicate of the s_iva_ns tax (Not Subject To VAT (services)) where we also see that the refund sign was wrong. opw-5079297 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#230663 Forward-Port-Of: odoo/odoo#229752
This fixes an editor issue where pasted plain text could lose an active style, such as bold, when inserted into an empty formatted area. Users can now rely on selected formatting being preserved while writing descriptions or other rich text content.
Original PR description
Problem: When text is inserted inside an empty format, the format is lost. Cause: After https://github.com/odoo/odoo/commit/ae33ca3d38d4a5adaad3015f036321d473713638, any empty format gets removed if content is inserted inside. Solution: Only remove the empty format if a media element is added. This preserves styling when inserting plain text inside an empty format. Steps to reproduce: 1. Copy some text from somewhere. 2. In an empty task description, press CTRL+B. 3. Press CTRL+SHIFT+V. 4. Notice that the text is not bold, even though the format was active. task-5136314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230051
A problem in the Expenses app could cause an error message to be incorrectly defined, potentially preventing users from seeing the intended guidance. This fix ensures the message is raised properly so users get clearer feedback when an expense action cannot be completed.
Original PR description
in 953fac5, the new error was not given the proper arguments Forward-Port-Of: odoo/odoo#229488
Point of Sale product search now returns all relevant products that match the search text, instead of stopping at exact matches. This helps cashiers find the right item more reliably, including similar product names and variants.
Original PR description
The POS search only returned products with an exact match (when existing), ignoring other relevant products that partially matched the search string. Steps to reproduce: 1. Create a product "TEST" - Create a variant with attributes value including "TEST" and "OTHER". 2. Create a second product "TEST 2". 3. Open the POS. 4. Search for "TEST". 5. Only "TEST" is shown; "TEST 2" is missing, even with "Search more". To align with the behavior introduced in v18, I’ve removed the exact match condition, as it no longer appears necessary due to the absence of fuzzy search. I’ve also adjusted the logic to perform the search on `product.product` instead of `product.template`. opw-4958141 Forward-Port-Of: odoo/odoo#230535 Forward-Port-Of: odoo/odoo#221520
This fixes the validation used for SEPA Direct Debit token payments so mandates are accepted or rejected based on the correct expiration date logic. It helps avoid valid future-dated mandates being wrongly blocked during payment processing.
Original PR description
The check to ensure that the mandate used in a token payment is still valid had two issues: - It was comparing a date (the mandate's end date) with a datetime. - It was incorrectly rejecting mandates expiring in the future, while it should have done the opposite. Forward-Port-Of: odoo/enterprise#96426 Forward-Port-Of: odoo/enterprise#96143
This fixes when French POS order integrity hashes are created so they use the complete finalized order data. It prevents legitimate orders from being incorrectly flagged as altered during inalterability checks, improving trust in compliance reporting.
Original PR description
Description of the issue/feature this PR addresses:
Starting from version 18.0, inalterability hashes in the FR localization are sometimes calculated with incomplete data, leading to incorrect `l10n_fr_hash`. Related orders are then wrongly flagged as altered when running the POS Inalterability Check.
Current behavior before PR:
When you post a POS order and a related draft order exists, Odoo updates the existing order with the new vals. Because `{'state': 'paid'}` is amongst the new vals, it triggers the generation of the `l10n_fr_hash` before the order is fully processed. For instance, the hash will be generated before a new payment line is added for change with `_process_payment_lines()`.
Desired behavior after PR is merged:
The hash should be generated at the end of the order processing, with the final write in `action_pos_order_paid()`.
Forward-Port-Of: odoo/odoo#229129
Forward-Port-Of: odoo/odoo#226032Sales order lines now keep the selected packaging unit, such as a pack of 6, when a user edits or confirms a product variant. This prevents quote and order quantities from unexpectedly reverting to single units, reducing order entry mistakes.
Original PR description
## Versions
18.2+
Note: 18.4 needs `product.uom_id` to be replaced by `product.uom.id` to work properly.
## Issue
On a SO, if a product has variants and packaging is allowed, modifying the variant resets the packaging to units.
## Steps to reproduce
*Ensure "Units of Measure & Packagings" is enables in Sales' app's settings*
- Create a new product
- Under "Attributes & Variants" tab, add the following:
- Color: add 2 colors;
- Legs: add 2 legs;
- Under "Sales" tab, select "Pack of 6" for "Packagings" (under "Upsell & Cross-Sell" section);
- Create a new quote and add that new product:
- Change its "Unit" for "Pack of 6";
- Modify the product variant by clicking the pen button next to the product name (appear on hover):
- Click "Confirm" (no changes needed);
- See the order line's product's units change back to "Units".
opw-4814166
Forward-Port-Of: odoo/odoo#224574Changing the quotation template on a sales order now removes the previously linked quote calculator spreadsheet. This prevents sales teams from using calculator data from the old template and keeps quotations aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587 Forward-Port-Of: odoo/enterprise#95861 Forward-Port-Of: odoo/enterprise#93970
An unstable automated test for the online shop was removed from version 18 releases because it was causing random failures in the validation system. This does not change customer-facing behavior, but it helps make release checks more reliable.
Original PR description
Versions -------- - 18.0 - saas-18.2 - saas-18.3 - saas-18.4 Issue ----- The `test_toggle_contact_us_button_visibility` causes random errors in runbot. Cause ----- Unsure, but with commit 26d22fc975e3f removing jQuery from `VariantMixin`, the random error no longer seems to pop up. Solution -------- Remove the test for versions before 19.0. runbot-145473 Forward-Port-Of: odoo/odoo#230728
Restaurant point-of-sale bill splitting now closes correctly once the last split item has been paid. This prevents staff from being left on a zero-balance split screen, reducing confusion and keeping checkout flow smooth.
Original PR description
When splitting a bill, a specific flow would leave the bill splitting screen open event when everything was paid. Steps to reproduce: ------------------- * In pos restaurant add 2 product to the order * Select Action > Split * Select a product * Click Pay(ment) and validate the payment * Continue * Select the last product * Click Pay(ment) and validate the payment * Continue > Observation: The Bill splitting screen is still open at 0$ Why the fix: ------------ When one or more products are selected a new order is created with those products. If the quantities match, it's the last payement for that bill, we can directly pay. The original order will then be closed. opw-5006042 Forward-Port-Of: odoo/odoo#230536 Forward-Port-Of: odoo/odoo#228991
Demo chat messages from Alex now display Alex as the sender instead of Odoobot. This makes the sample Discuss data clearer and avoids confusion when evaluating or demonstrating chat conversations.
Original PR description
Before this commit, Alex's messages in discuss demo data were displayed as "Odoobot" rather than Alex. This happens because message had proper author_guest_id but no author_id defined, thus it had default value Odoobot and since [1] the author_id has precedence over `author_guest_id`. Before [1] there was no bug because the server returned formatted data of a single author as a persona, and guest_author_id had precedence over author_id. [1]: https://github.com/odoo/odoo/pull/211868 Before <img width="811" height="279" alt="Screenshot 2025-10-10 at 16 18 53" src="https://github.com/user-attachments/assets/862cfd18-24a0-485f-89b6-77277b9098ad" /> After <img width="815" height="280" alt="Screenshot 2025-10-10 at 16 17 45" src="https://github.com/user-attachments/assets/f83b98dd-ffb1-4419-851c-f34f3261792d" />
Sale orders linked to Gelato are now handled in a safer two-step process to avoid creating duplicate production orders when confirmation is retried. This helps prevent accidental duplicate fulfillment and related customer service or cost issues during payment processing.
Original PR description
In case on a concurrent update happen in the same transaction as the sale order confirmation (was observed during payment transaction post-processing), we may currently create duplicate Gelato orders on each retry. This commit avoid duplicate order creation by splitting the Gelato order creation in two steps: - during the sale order confirmation we create a 'draft' order on Gelato - on post-commit/post-rollback we either try to confirm or delete the Gelato draft order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228107
This update adjusts an internal mail test related to link previews so it is formatted more reliably. It helps maintain product quality by making automated checks easier to understand and less prone to false failures, with no direct change for end users.
Original PR description
Forward-Port-Of: odoo/odoo#230833
This change prevents pricelist rules based on another pricelist from being saved unless the referenced pricelist is provided. This avoids incorrect price calculations when rules are created outside the standard user interface, such as through custom screens or integrations.
Original PR description
Before this commit, only a view-level required attribute ensured that pricelist items with `base=='pricelist'` have a `base_pricelist_id` set. Creating pricelist items from a custom view or the API or the shell could result in missing values for this field, causing `_compute_base_price` to incorrectly assume that `base=='list_price'`` This commit introduces a new constraint ensuring any pricelist whose price is `base`d on an "Other Pricelist" has a value for `base_pricelist_id`. Note: in the views, `base_pricelist_id` is required if `compute_price == 'formula' and base == 'pricelist'` but the first condition is not neeeded because `_onchange_compute_price` sets `base` to `'list_price'` when `compute_price!='formula'` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230438
Links added to Social Marketing posts are now recognized correctly when their parameters include commas or similar special characters. This prevents previews from cutting the link too early, helping users share accurate URLs in social posts.
Original PR description
**Steps to reproduce:** - Go to `Social Marketing` app. - Click on `New Post`. - Select Facebook for preview (should not matter). - Write a message with an URL which have comma-separated parameters. (e.g 'TEST URL https://example.be:8080/path/res-123/ext/?param1=v1,v2,v3') - URL is cut on the first comma in the preview. **Issue:** URL regex did not match URLs containing comma-separated query parameters, causing them to be truncated. **Fix:** Updated the regex to include commas. opw-5042131 Forward-Port-Of: odoo/enterprise#94220
This fixes demo chat data so messages from Alex are displayed as coming from Alex instead of Odoobot. It improves the accuracy of demo conversations and avoids confusion when users review or present the Discuss app.
Original PR description
Before this commit, Alex's messages in discuss demo data were displayed as "Odoobot" rather than Alex. This happens because message had proper author_guest_id but no author_id defined, thus it had default value Odoobot and since [1] the author_id has precedence over `author_guest_id`. Before [1] there was no bug because the server returned formatted data of a single author as a persona, and guest_author_id had precedence over author_id. [1]: https://github.com/odoo/odoo/pull/211868 Before <img width="811" height="279" alt="Screenshot 2025-10-10 at 16 18 53" src="https://github.com/user-attachments/assets/862cfd18-24a0-485f-89b6-77277b9098ad" /> After <img width="815" height="280" alt="Screenshot 2025-10-10 at 16 17 45" src="https://github.com/user-attachments/assets/f83b98dd-ffb1-4419-851c-f34f3261792d" />
Point of Sale now saves large local data batches one at a time instead of all at once. This reduces overload and helps prevent timeouts or failed saves when handling high volumes of sales data.
Original PR description
When saving large datasets to IndexedDB, all batches were started in parallel. This could cause excessive open transactions, long execution times, and premature transaction aborts due to the timeout. With this commit, batches are now processed one at a time, ensuring that each batch completes before starting the next. This improves stability and prevents transaction overload when handling high volumes of data. opw-5052956 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226129
Cashiers can now enter numeric passwords using a physical keyboard when the password popup is open. This fixes a point of sale usability issue where staff had to rely only on the on-screen number buttons, making login and cashier switching faster and more convenient.
Original PR description
Before this commit, when the NumberPopup was open (for example, when entering the cashier password), the keyboard input was ignored because the overlay manager blocked all keyboard events while any popup was active. As a result, it was only possible to use the on-screen number buttons. After this commit, the keyboard input is allowed when a NumberPopup is open, enabling users to type the password directly using the keyboard. opw-5152235 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230626