Daily updates from Odoo
Wednesday, October 1, 2025
45 changes · saas-18.3
Resolved issues and error corrections
This update corrects an internal sales and manufacturing test so it reflects that kits can be invoiced before delivery when configured to invoice ordered quantities. It helps keep automated checks aligned with expected business behavior and reduces the risk of false build failures.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796 Forward-Port-Of: odoo/odoo#227870
The website shop now handles invalid category values in product page URLs more gracefully. This prevents a server error when someone opens or tampers with a link containing malformed category information, improving reliability for visitors.
Original PR description
Currently, an error occurs when the `category` is received as a `string` and the code tries to evaluate `int(category)`. **Steps to reproduce:** - Install the `website_sale` module. - Open a product page in the website with an `invalid category` parameter, for example: `http://localhost:8069/shop/warranty-39?category=1;` **Error:** `ValueError: invalid literal for int() with base 10: '1;'` **Root Cause:** At [1], the code directly calls `int(category)` without validating the input. When the parameter contains `non-numeric` characters, Python raises an `error`. **Fix:** This commit ensures raising a `ValidationError`, improving the `error message` clarity, when users manually input `invalid or tampered` category values in the `URL`. [1]: https://github.com/odoo/odoo/blob/d32f98dd199f80d2b0031bd52a6ff74411c3e7e0/addons/website_sale/controllers/main.py#L1827 sentry-6658317828
The chatter follower menu now stays open when a user removes a follower, making it easier to remove several followers in one session. The related edit subscription action now closes the menu consistently, reducing confusion in day-to-day record collaboration.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ Removing multiple followers from the chatter is cumbersome because the followers dropdown closes immediately after each removal. Additionally, clicking 'Edit Subscription' next to 'Unfollow' did not close the dropdown, which was inconsistent with expected behavior. **Current behavior before PR:** --------------------------------- - Removing a follower from the chatter closes the followers dropdown immediately - Clicking 'Edit Subscription' next to 'Unfollow' leaves the dropdown open **Desired behavior after PR is merged:** ----------------------------------------- - The followers dropdown remains open after removing a follower, allowing multiple removals without interruption - Clicking 'Edit Subscription' next to 'Unfollow' closes the dropdown as expected **Task:** 4943867
Spanish POS orders using TicketBAI now automatically retry the previously failed submission when a new order is paid. This helps prevent one failed tax submission from creating a growing backlog of unsubmitted sales records.
Original PR description
Currently, the post failure of a single pos order can easily cause a backlog of more unposted orders since new orders will not be posted until the chain head is posted. Steps to reproduce ----- 1. Validate a pos order and have the TicketBAI post fail 2. Validate another pos order 3. The post for the second order is never attempted Cause ----- `_check_can_post()` ensures that new orders are not posted if the chain head was not posted successfully. During normal operation, it is common for many new orders to be paid before the user has a chance to manually retry the chain head post in the backend, causing a backlog of unposted orders. Solution ----- During `action_pos_order_paid()` retry the chain head post if is not sent. opw-4669823 Forward-Port-Of: odoo/odoo#228477
This fixes a crash that could happen in Discuss calls when an update arrived for a session that had already been removed. It improves reliability for users by safely ignoring outdated session updates instead of interrupting the experience.
Original PR description
Before this commit, since a regression introduced in https://github.com/odoo/odoo/pull/228601 A traceback could occur when updating a session that does not exist. For example if the event is received after the session is removed. Forward-Port-Of: odoo/odoo#229166 Forward-Port-Of: odoo/odoo#229073
Customers can now successfully add their selected free product when redeeming a coupon that offers a choice among tagged products. This fixes a checkout issue that prevented the reward item from being added to the cart, reducing friction in promotional campaigns.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a coupon program with a free product reward using a product tag; 2. generate coupons & copy a coupon code; 3. have 2 or more products with the tag; 4. go to /shop & add any product to your cart; 5. go to checkout; 6. apply coupon code; 7. select a free product; 8. click "Use". Issue ----- Product isn't added to the cart. Cause ----- On forward porting a fix for a similar issue in bb92ba5fbba94, it accidentally checks for the `product_id` in `request.env` instead of `request.env.context`. As no `product_id` is found, no product is added. Solution -------- Check `request.env.context` instead of `request.env`. opw-4979939 Forward-Port-Of: odoo/odoo#229157 Forward-Port-Of: odoo/odoo#224166
This fixes an issue where packaging details could be missing on products with a single variant. It ensures product packaging information is correctly applied, helping avoid incorrect or incomplete product setup in daily operations.
Original PR description
e158730ba16e898a13dd9a98ed96fa30fa95ab6f recently fixed a situation where one-variant products had duplicated packagings. In the aforementioned commit, we concluded that the logic to write (again) the templates values for variant-stored fields was useless because already applied to the generated variants. Nevertheless, while trying to remove in master this logic, we noticed that those varlues are only applied to variants of templates having at least one attribute line, whose creation will trigger the variants creation. This commit therefore partially reverts the previous commit, bringing back the first solution that is still the best approach in the end. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229080
This fixes a problem where sale orders linked to projects could become blocked if a related analytic account had been deleted. Users can now update the Project field on affected sale orders without encountering an error, improving reliability for sales and project workflows.
Original PR description
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an…
# Issue: In a sale order, if any of the so lines contains the ID of a deleted analytic account in its analytic_distribution field, then updating the project_id field is impossible as it raises an error. # Cause This is caused because _compute_analytic_distribution() tries to retrieve 'root_plan_id' from all ids without checking if records exists. # Fix This commit add an exists() check on analytic.accounts retrieved from analytic_distribution field and clear the non-existing records ids from the field. # Steps to reproduce - Install sale_project and accountant modules - Check "Analytic Accounting" in the Accounting settings - Create a new project "Test P", set it up "Billable", with a new Analytic account "Test AC" (field "Project" tab "Analytic") - Create a new sale order "Test SO", add a few products and set up the Project field to "Test P". Save the sale order. - Delete the analytic.account "Test AC" - Go back on "Test SO", try to change the field "Project" - a Missing error is thrown --- Current behavior before PR: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can't be updated anymore. Desired behavior after PR is merged: When creating a sale order and binding it to a project with an analytic account, then deleting the analytic account, the field "Project" on the sale order can be updated. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224895
This fix prevents manufacturing planning from failing when work orders have extremely small duration values. It ensures schedules can still be calculated reliably, avoiding errors that could block production planning.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227253
Point of Sale now filters quotations and orders by the customer currently selected at checkout. This prevents staff from seeing unrelated customer documents, making order lookup clearer and reducing the chance of selecting the wrong record.
Original PR description
Before this commit, when selecting a customer in the POS and clicking Actions → Quotation/Order, all quotations and orders were displayed instead of filtering by the selected customer. This commit ensures that only the quotations/orders of the selected customer are shown. opw-5074052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228285 Forward-Port-Of: odoo/odoo#227448
A website sales test was updated so it prepares price lists before checking GeoIP-based cart pricing. This prevents false test failures in databases without demo data, improving reliability without changing customer-facing behavior.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a database without demo data; 2. run `test_cart_new_pricelist_from_geoip`. Issue ----- Test fails, due to the order not having a pricelist. Cause ----- Pricelists aren't enabled by default without demo data. Solution -------- Call `self._enable_pricelists()` at the start of the test. runbot-232989
This fixes an issue where highlighted design effects in website page templates could be carried into newly created pages in the wrong internal format. Business users creating new website pages from templates should now see highlights render correctly and consistently.
Original PR description
Starting from [1], the code from the "Snippets Preview" and the "New Page Templates Preview" was adapted to be able to build a highlight using its simplified format when provided in XML. The goal of this PR is to fix the new page DOM when a template with highlights is selected. The DOM will be simply cloned and used for the created page, so we need to reset the inner highlights to their minimal format. [1]: https://github.com/odoo/odoo/commit/4a29fa66003ce1f42a7011bc56fc019f34a887f5 task-4215788 Forward-Port-Of: odoo/odoo#185820
Fixed an issue where the rental schedule could hide later rental orders for products rented again with the same serial numbers. Businesses can now see the full set of rental bookings, helping avoid undercounting availability or missed follow-up on repeated rentals.
Original PR description
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN.…
**Current Behavior:** With rental transfers enabled, renting a product with a serial number multiple times will result in the rental schedule only showing one of multiple rental orders for that SN. **Expected Behavior:** All rentals for the same SN should appear in the rental schedule. **Steps to Reproduce:** - Go to Rental > Configuration > Settings and enable Rental Transfers - Create a new product that is storable, can be rented, and is tracked by unique serial number - Receive 25 of the product with assigned serial numbers - Create and confirm a rental order for 25 units of product - Validate both OUT and IN transfers - Duplicate the rental order and confirm it - Check Rental > Schedule -> Odoo says 25 total units across the original and duplicate orders, but they each have 25 **Cause of the Issue:** Previously, commit ed5fd2693fc fixed a bug where all serial numbers would display regardless of whether they were involved in a rental. This introduced this bug, where only the first stock move line with a distinct serial number would be shown in the rental schedule. **Fix:** Change the "SELECT DISTINCT ON" to "sml". We can get all distinct stock move lines as we can expect SNs to appear multiple times. opw-5003247 Forward-Port-Of: odoo/enterprise#95315
Free products added through loyalty rewards now use the reward description set by the business instead of the product's default name. This makes sale orders clearer and keeps loyalty behavior consistent with point-of-sale flows.
Original PR description
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program…
Currently, the reward's product name is used as the SOL name for the free product, which can be confusing. **To reproduce this issue:** 1) Install the sale_loyalty module. 2) Create a loyalty program that grants a free product. 3) Manually update the reward's description. 4) Create a SO with a SOL containing that product 5) Apply the reward and observe the behavior. **Issue / Cause:** - The free product's description is taken from the reward product's name instead of the manually updated description. - This is incorrect because, in the point of sale, the name is taken from the reward's `discount_line_product_id` rather than the `reward_product_ids`. https://github.com/odoo/odoo/blob/0abdcd9ef6ad3fc932dc0eb46d8aa973b00c34c2/addons/pos_loyalty/static/src/overrides/models/pos_order.js#L1162 **Solution:** To resolve this inconsistent behavior, the free product name in the sale order line will now be taken from discount_line_product_id. opw-4982774 Forward-Port-Of: odoo/odoo#229152 Forward-Port-Of: odoo/odoo#223755
Fixes several issues that could make Knowledge comments disappear, fail to load when switching locked articles, or crash in code blocks. This helps users keep comment discussions visible and accessible across article editing and read-only viewing workflows.
Original PR description
### Issue 1: Summary: When a user adds a comment inside a baseContainer element, the comment beacons created during the comment insertion can be discarded during the document normalization step. How…
### Issue 1: Summary: When a user adds a comment inside a baseContainer element, the comment beacons created during the comment insertion can be discarded during the document normalization step. How to reproduce: - Open an article in Knowledge. - Select text and change the block style from "Paragraph" to "Normal" using the powerbox. - Add a comment on the selected text using the powerbox. - Write a message in the comment thread. - Save and reload the article. Issue: - The comment beacons disappears from the editor and the user can't see it anymore. Resolution: When the editor is initialized, `div` are not yet categorized as paragraph related elements. The `comments_plugin` logic to identify valid positions for comments beacons should take that into account and allow elements which are candidates to be a paragraph related element. ### Issue 2: Summary: There was an issue where comments were not displayed when switching from a locked article to another (read-only). How to reproduce: - Create two articles and add a comment on each. - Lock both articles (so that they are effectively read-only). - Switch from one article to the other. Issue: - Comments are not displayed to the user. Resolution: When switching between read-only articles, `KnowledgeHtmlViewer` is not fully reloaded and continues using the same `CommentBeaconManager` instance for the newly opened article. As a result, comment beacons are not displayed when switching article. The simplest solution to this issue is to re-instantiate a new `CommentBeaconManager` whenever the HTML value changes to ensure comments are correctly displayed. ### Issue 3: There is an issue in the logic of `computeVerticalDimensions` to display comments. If the `top` value of a thread in the article is `0`, it will be filtered out and not displayed because `top` was used as a boolean value. Instead, it should properly consider `top` as a finite number to display the comment or not. Note: This issue is not easily reproducible because there are few configuration where a comment would have a top value equal to 0. ### Issue 4: There is a crash when inserting a knowledge comment in a `/code` block: In this previous [task], insertion in `pre` elements was filtered to prevent non-phrasing content from being inserted (as it is invalid per the html specification). To prevent a crash, knowledge comments will be disabled in `<pre>` elements, as they rely on `anchor` elements for the comment position in the article body. [task]: 216e9eb task-4984152 Forward-Port-Of: odoo/enterprise#91408
Users can now create actions in Documents that generate journal entries for journals marked as Credit Card. This fixes a blocker for creating credit card statements through automated document workflows.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868
Swedish Bankgiro accounts are now marked with the correct account type in payment XML files instead of being treated like standard bank accounts. This helps ensure payment files comply with expected banking formats and reduces the risk of rejected or misclassified payments.
Original PR description
Issue: The only possible value for the bank account type is "BBAN". For a 'bankgiro' account it should be "BGNR". Solution: Input "BGNR" in the XML if the bank account type is 'bankgiro'. opw-5063368 Forward-Port-Of: odoo/enterprise#95467
Fixes an issue where point-of-sale receipts could show the selected shipping date as the previous day for users in time zones behind UTC. This helps staff and customers see the correct delivery date on receipts when using Ship Later.
Original PR description
In this bug, the shipping date in pos receipt is set to previous dates. To reproduce the bug: 1- Setup a database with point_of_sale app installed 2- In configuration -> Setting, check Allow Ship Later option for a pos shop. 3- Change the browser timezone to a US timezone. In chrome it can be in Console -> Sensors -> Location. 4- Open POS register, select a product, choose payment and use Ship Later, to pick a date. 5- After validating the order, you can see the wrong shipping date is shown in the recipt. This is related to #215140 in which the shipping date bug is fixed when the date is picked. However, in generation of receipt a new PosOrder object is created, in which there is a need to explictly deserilizing shippingDate to avoid unwanted timezone effects. opw-5009476 Forward-Port-Of: odoo/odoo#224586
Customers viewing an online order that includes a manufactured product will no longer see the manufacturing date repeated. This keeps the order portal clearer and avoids confusion when checking manufacturing information.
Original PR description
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and…
**Steps to reproduce:** 1.Install `website_sale` and `sale_mrp`. 2.In settings, enable `multi-route` and `unarchive` the Replenish MTO route. 3.Create a product with routes -> `Replenish MTO` and `Manufacturing` then publish it on the website. 4.Buy the product from the website and make the payment. 5.Go to My Account → Your Orders → Open your sale order. 6.In the Manufacturing section, the date appears twice. **Issue-** <img width="604" height="186" alt="image" src="https://github.com/user-attachments/assets/e4164564-8555-4005-8282-20e6f5de7e55" /> - Date found twice in Portal View of sale order **Cause-** https://github.com/odoo/odoo/blob/097c04156517bd97a2789bde22ffd0c69c0bf6bf/addons/sale_mrp/views/sale_portal_templates.xml#L18-L27 - Here using same field two time one it with condition and other is without condition so in some case when condition satisfied then same field are coming twice **Solution-** - Remove Conditional field because no meaning of using same field inside and outside of the condition **opw - 5096009** Forward-Port-Of: odoo/odoo#227997
This update fixes an unreliable automated test for the HTML editor toolbar by ensuring the toolbar is fully ready before the test continues. It helps keep quality checks stable and reduces false failures during release validation.
Original PR description
The editor toolbar is affected by [1] and therefore needs to be properly awaited for. This test was missed by [2], probably because it did not explicitly waited for the toolbar itself. runbot-231692 [1]: https://github.com/odoo/odoo/pull/211426/commits/54da715df84789f9a1acc0cfc91be41dcdbab140 [2]: https://github.com/odoo/odoo/pull/213090 Forward-Port-Of: odoo/odoo#227989
This fix makes the lot selection field read-only in cases where entering a lot there would not actually apply it to the stock transfer. Users are prevented from thinking a lot was provided when the receipt would still fail validation, reducing confusion in warehouse operations.
Original PR description
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the…
### Steps to reproduce: - In the setting enable lots and serial numbers - Create a product tracked by LOT - Create and confirm a receipt for 1 unit of that product - Create a new lot: LOT001 from the move in the picking form - Click Validate #### > Invalid operation: you need to provide Lot/Serial numbers of the product ### Cause of the issue: The set method of the `lot_ids` field of the `stock.move` model does nothing for product tracked by lots: https://github.com/odoo/odoo/blob/7a8f9b7fe4dded4cfa140103d51b52e08149cadb/addons/stock/models/stock_move.py#L575-L579 In particular, while the lot appears on the move in the view, none of the move lines refer to it and the transfer can not be validated as indeed no lots are provided to these reservations. ### Fix: The feature of writing `lot_ids` for lots has been introduced in https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e https://github.com/odoo/odoo/blob/1c52e2e9e8e00a19e2db00bf70d658496f9a0f29/addons/stock/models/stock_move.py#L596-L600 But this major refactoring can of course not be backported in 18.0. Therefore, it was decided put the field in readonly when its set method is inefficient. opw-5093217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228840
This update makes an internal purchase inventory test independent of country-specific settings that could change product behavior. It helps keep automated checks reliable when Kenyan localization modules are installed, reducing false test failures without changing business workflows.
Original PR description
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase…
The test `test_receive_negative_quantity` is failing when run with the `l10n_ke` module installed. The failure occurs during the validation of the picking created from a negative-quantity purchase order. The test assumes the product is of type `consu`, which bypasses stock reservation. However, the following [XML default](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu_stock/data/ir_default.xml#L5) in l10n_ke forces the product type to `product` (stockable), triggering reservation logic. Since the ordered quantity is negative, no reservation occurs, and the `_sanity_check()` fails with: `You cannot validate a transfer if no quantities are reserved.` We fix this by explicitly setting a product with the type `consu` in the test. This ensures that reservation is skipped regardless of which modules are installed or what defaults they apply. runbot:[108147](https://runbot.odoo.com/odoo/error/108147) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228583 Forward-Port-Of: odoo/odoo#221042
The project dashboard now prevents editing a milestone's quantity percentage when it is not linked to a sales order line. This avoids confusion by making the field clearly unavailable in cases where changes cannot be applied.
Original PR description
**Steps to Reproduce:** - Install sale_project. - Go to the project dashboard. - Click on Edit milestones. **Isuue:** When a sales order line exists, the quantity percentage can be updated. When no sales order line exists, the quantity percentage cannot be updated. **Fix:** Make the field readonly when no sales order line is linked. task-5068312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227922
Fixes the XML field name used for linked invoice dates in Italian electronic invoicing. This prevents affected invoices with a customer reference from being rejected by the Italian exchange system due to an invalid format.
Original PR description
The name for the date in DatiFattureCollegate (56e08bb091d39a18ea1c8e7699321b953a8823e1) is wrong. It is not DataDocumento but Data as per https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiGenerali/DatiFattureCollegate/Data/18
How to reproduce the issue:
- With l10n_it, create an invoice and fill the customer reference field.
- Generate the xml and validate through https://fex-app.com/servizi/verifica
- The following error related to the date happens: E-invoicing (Italy) La fattura elettronica è stata rifiutata dall'SdI. File non conforme al formato : Invalid content was found starting with element 'DataDocumento'. One of '{Data, NumItem, CodiceCommessaConvenzione, CodiceCUP, CodiceCIG}' is expected. riga: 80 - colonna: 24
opw-5082016
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227260Product pages with many images now keep the selected thumbnail centered in the image viewer, so shoppers can access all thumbnails instead of having some cut off at the screen edge. The update also improves mobile browsing by allowing easier swipe navigation through product images.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Add a bunch of extra images to a published product; 2. enable zoom-on-click via editor; 3. click on an image to zoom it; 4. scroll through images. Issue ----- With too many images added, the thumbnails on the bottom are cut off on the edges of the screen, making it impossible to click on them. Cause ----- The thumbnail row element doesn't get updated when selecting a new image. Solution -------- Define a `_updateCarousel` method which adds a `transform: translate` operation to the thumbnails, moving them such that the currently selected image's thumbnail gets centered on the screen. Call this method on mounting, and again on any render (image change). Bonus: add `touchstart` & `touchmove` hooks to enable easy swiping through the carousel on mobile. opw-4937009 opw-4908881 Forward-Port-Of: odoo/odoo#229256 Forward-Port-Of: odoo/odoo#224981
This fixes an issue where the IoT Box browser could reopen using an outdated page from the database instead of the address set in its configuration file. The browser settings now preserve the configured URL when saving display orientation, helping devices return to the expected page after reopening or rebooting.
Original PR description
The browser on the IoT Box was always reopening on the url saved in the database instead of the one saved in odoo.conf. When opening the browser, we used to set the orientation and save it in the configuration. As we only set the orientation and not the url at this point, we were mistakenly removing the url from odoo.conf. As it was not set anymore, when reopening the browser later (e.g. after reboot), no url was available in conf, so we fell back on the db's one. Task: 5103536 Forward-Port-Of: odoo/odoo#229002
Long category names in the online shop sidebar no longer disrupt the category list layout. This keeps product browsing pages visually consistent and easier to navigate for customers using categories with lengthy names.
Original PR description
__Issue:__ In the product categories sidebar (`#products_grid_before`), nested `<li>` elements could become wider than their parent `<ul>` when the category names were long (e.g., "Untersuchungshandschuhe"). This caused the parent <ul> to expand in height before the child and broke the visual layout. __Fix:__ Force `<li>` elements inside the `#categories_recursive` list to respect their parent width by applying `width: 100%` This keeps the sidebar layout consistent even with long category names. - opw-5075226
This fix prevents subscription invoices from overwriting correct combo section information or adding unnecessary section values. It helps keep invoice lines organized accurately, reducing confusion for customers and sales teams.
Original PR description
This commit improve fix of PR https://github.com/odoo/enterprise/pull/90989 to avoid overriding right combo section values and avoid setting unnecessary values on the section. opw-5069278 Forward-Port-Of: odoo/enterprise#94776
This fixes incorrect buyer document values on Indonesian e-Faktur invoices. Contacts using “Other ID” or “National ID” will now produce the expected document labels, helping avoid invoice reporting mistakes.
Original PR description
the byer document has a wrong value in others and NIT. so this commit change the values to `Other ID` and `National ID` To check values: go to fields and search for `l10n_id_buyer_document_type` opw-4974469 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222346
This update corrects an internal sales test so it uses the configured sale confirmation email template instead of assuming a fixed one. This helps ensure payment confirmation behavior is tested accurately when businesses customize their email settings.
Original PR description
The email template for the sale confirmation can be changed through the config parameters so it's better to read it directly from there instead of having it hard-coded. This now correctly tests the function it's testing. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226240
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
Original PR description
After DIOT 2025 rework in 4e6bee49e98b055e5aebe89fb19ab6317003b682 the report is missing some es translations Steps to reproduce: - With an MX Company and Spanish es_419 language set - Open Accounting > Reporting > Tax Report - Choose report Diot MX opw-5016650 Forward-Port-Of: odoo/odoo#229132 Forward-Port-Of: odoo/odoo#229085
The cohort report export button is now disabled when there is no data to export. This prevents users from triggering an error in reports such as Helpdesk Ticket Analysis when the database has no matching records.
Original PR description
Currently, an error occurs when user tries to export data on cohort view with no data. Steps to replicate: - Install `helpdesk` (without demo data). - Go to `Helpdesk > reporting > Ticket Analysis` and go to cohort view. - Click download and error will occur. - If error doesnt occur, click on `Measure > Count`, and click Download again. Error: `IndexError: list index out of range` Cause: - The export button remained enabled even when no data available, this caused the export to be called without any data that caused the `Indexerror` at [1]. Solution: - Disabled the export button when no data in cohort view. [1]: https://github.com/odoo/enterprise/blob/475a802aa3e748a905be83c0f6408f8c20f03905/web_cohort/controllers/main.py#L30 sentry-6831823426 Forward-Port-Of: odoo/enterprise#93050
Fixes an error that could occur when users edited budget amounts after changing the report date range. Budget lines are now matched to the correct monthly period, preventing duplicate incomplete entries and allowing users to continue updating budgets reliably.
Original PR description
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting`…
Currently, an error occurs when user editing the budget report items. Steps to Reproduce [Video](https://drive.google.com/file/d/1bz0GEQjwxQrckzcEHdYPfvaA5M43lmFF/view): - Install the `Accounting` module. - Go to `Profit and Loss` > `Budget` and `create a budget`. - Select `custom dates (e.g., start: 01/01/2025, end: 12/10/2025)` and change the amount of a budget line. - Change the `date range (e.g., start: 01/10/2025, end: 12/10/2025)` and change the amount again. - `Switch back to the first date range` (start: 01/01/2025, end: 12/10/2025) and try changing the amount once more. `TypeError: unsupported operand type(s) for +: 'float' and 'NoneType'` This error occurs when a user editing the budget report items. When user enters a date period, the system creates budget items for the first date of every month within that range. If the user then changes the date period to the next date of the same month, the system attempts to fetch the existing budget item `[1]` for that range. However, due to the start date alignment, it fails to fetch the correct budget item and instead creates an extra one `[2]`. Later, when the system checks again from the first date of the same month as the start date, it finds this extra budget item, for that the amount is None, which raises the error `[3]`. This commit ensures that when fetching existing items and generating the start month dates `[4]`, the system always uses the first day of the month as the `start date` so that the flow is maintained.. [1]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L44-L49 [2]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L75-L79 [3]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L72 [4]- https://github.com/odoo/enterprise/blob/1df83837a2aec4801b34a9a7ab0cd68f640b4fd6/account_reports/models/budget.py#L58-L61 sentry-6883207225 Forward-Port-Of: odoo/enterprise#95090
Shop Floor now displays manufacturing by-products in the right place and with clearer quantity information. This reduces confusion for operators by hiding irrelevant location details and opening the correct creation dialog when adding tracked by-products.
Original PR description
Shop Floor by-products fixes: - show by-products not linked to a workorder only on mo card - do not show locations for by-products - always show quantity done / to consume quantity - clicking (+) on tracked by-products now opens the create quant dialog rather than the quants list view task: 4781451
This fixes an issue where engineering change orders could not correctly record very small bill of materials quantity updates when units of measure allowed more than two decimals. Businesses using precise measurements can now track component quantity changes accurately during product revisions.
Original PR description
Steps to reproduce the bug:
- Go to Decimal Accuracy → Product Unit of Measure → set digits to 4
- Go to Units of Measure Categories → select a unit → set rounding to 0.0001
- Create a storable product “P1” with a BoM:
- Component C1: 1.0000 unit
- Create an ECO for the BoM with type BoM update
- Start the revision
- Go to V2
Problem:
You cannot update the quantity of C1 to 1.0003 (for example) because the system uses the default 2 digits instead of the UoM digits.
opw-5082488
Forward-Port-Of: odoo/enterprise#95470
Forward-Port-Of: odoo/enterprise#95180Ticket lists in Helpdesk now sort ticket references in a more natural order, especially after ticket numbers pass 100. This makes it easier for users to find the oldest or newest tickets without confusing number ordering.
Original PR description
**Issue** With the default `helpdesk.ticket` sequence, once users reach 100 tickets, ordering tickets by `ticket_ref` in the list view is unintuitive as it is a Char field (so '11' > '100') and the results are not useful if the user wants to see the oldest/newest tickets. opw-4891916 Forward-Port-Of: odoo/enterprise#95548 Forward-Port-Of: odoo/enterprise#93058
The Time Off view now uses the correct employee profile context when opened from My Profile. This prevents users from seeing a Missing Record error and allows them to access their time off information reliably.
Original PR description
**Steps to reproduce (without demo data):** - Install hr_holidays - Go to "My Profile" - Open "Time Off" **Issue:** Accessing Time Off from a user profile triggers a `Missing Record` error. **Cause:** The system was passing the user’s active_id to the employee record incorrectly. **Fix:** Now, when the context's active_model is 'hr.employee', the correct active_id is applied. **Commit issue:**https://github.com/odoo/odoo/pull/225839
This update adds checks to ensure keyboard shortcuts like bold, italic, underline, and strikethrough behave correctly when no text is selected. It helps prevent editing glitches and keeps the editor history clean for a smoother content editing experience.
Original PR description
Description of the issue this PR addresses: This PR adds test cases for formatting shortcuts (e.g., Ctrl+B) on a collapsed selection. An empty inline tag is inserted temporarily and auto-cleaned if unused, so no individual history step are created. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229233
This fixes an issue that prevented portal users from creating project tasks by sending emails to a project alias. Restoring this flow helps external collaborators and customers submit work requests without needing direct backend access.
Original PR description
The new safety belt introduced in 745f3accaf775550294d6f1bf562a0dcc15f7a08 made it impossible for portal users to create tasks by sending emails to the project alias. @moduon MT-11332 Forward-Port-Of: odoo/odoo#228986 Forward-Port-Of: odoo/odoo#225321
Fixed an issue where self-ordering kiosks could open to a blank screen when a point of sale used only a parent category with products in its child categories. The kiosk now selects an available child category so customers can browse and order normally.
Original PR description
Problem: When the available categories for a point of sale contain one parent category and its child categories and the parent category itself does not have any products, the code filters out the top…
Problem: When the available categories for a point of sale contain one parent category and its child categories and the parent category itself does not have any products, the code filters out the top categories as those that have no parent category. If, in such a case, no products belong to the parent category itself, the selected category is undefined which leads to a blank white screen and the javascript error visible on the console. Purpose: If there are no top categories, the screen should ideally load the current category computed before. This fix leads to the one of the child categories being the selected category and the kiosk screen loads properly Steps to Reproduce on Runbot: 1. Create a point of sale. Go to Settings, choose no presets and “Kiosk” in the self-ordering option. 2. Create a parent POS category and two child POS categories. 3. Ensure there are products belonging to the two child categories and none to the parent category 4. Open settings for the POS and choose only these three categories in the “Restrict Categories” section. 5. Go to the point of sale and open the kiosk. Click on “Order Now”. The white screen appears and the js traceback error is visible on the console opw-5058245 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes survey descriptions and end messages so embedded media like videos can be shown properly when respondents open a shared survey link. It prevents content added in the editor from relying on editor-only components that are not available in the public survey view.
Original PR description
Embedded components do not render when the html field content is displayed outside the editor, as their mechanism relies on the editor plugin. Solution: --------- Disable embedded components for the…
Embedded components do not render when the html field content is displayed outside the editor, as their mechanism relies on the editor plugin. Solution: --------- Disable embedded components for the survey messages (Description and End Message). Steps to reproduce: ------------------- * Create a new survey * Add a video as End Message or Description * Use the share link to view de survey * Video not showing Cause of the issue: ------------------- The new web_editor has a plugin system, and one option that is enabled by default is embedded_components. This option has been introduced in: https://github.com/odoo/odoo/commit/03f495c696030214c17e6479076571823513f60e According to the description: "It is forcibly set to false in HtmlMailField since embedded components can only be rendered inside Odoo." Observation : ------------ similar fix: https://github.com/odoo/odoo/commit/1446167e482745c71725563e56411948c3dd1f41 opw-5005752 Forward-Port-Of: odoo/odoo#224808
Active payment providers can no longer have their linked payment journal removed from the journal settings. This prevents payment failures caused by missing journal information and helps keep payment processing stable for companies using branch setups.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have an active payment provider; 2. create a branch company; 3. set payment provider's company to branch; 4. leave Payment Journal unchanged (parent company Bank); 5. go to Accounting / Configuration / Accounting / Journals; 6. open Bank journal; 7. open "Incoming Payments" tab; 8. enable the "Payment Provider" column; 9. unset the payment provider on the active provider's line & save; 10. attempt paying using the provider. Issue ----- > Error: psycopg2.errors.NotNullViolation: > null value in column "journal_id" of relation "account_payment" violates not-null constraint Cause ----- We shouldn't be able to change the related journal of active providers. Solution -------- Make the field read-only if the payment method is active. opw-5045000 Forward-Port-Of: odoo/odoo#229342 Forward-Port-Of: odoo/odoo#225187
Customer statement emails sent from child contacts now include the correct PDF details instead of an empty attachment. The statement button is also hidden when there are no transactions or nothing is due, reducing confusion for accounting users.
Original PR description
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and…
**Steps to reproduce:** 1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email). 2. Create an invoice with the child contact as customer and confirm it. 3. Go to the child contact and open the Customer Statement smart button. 4. Download the PDF → data is shown correctly. 5. Send the statement → the attachment in the sent mail is empty. **Issue:** - When sending customer statements via email from a child contact, the generated PDF attachment contains no data, showing empty amounts and transactions. - Additionally, the "Customer Statement" button was still visible even when the total due was zero. **Cause:** - The button visibility condition checks for `total_due == 0.0 and not has_moves`, which didn’t properly cover all use cases. **Solution:** - Update button visibility condition to: `invisible="not has_moves or total_due == 0"` ensuring it is hidden when there are no moves or the total due is zero. **opw-5009182** Forward-Port-Of: odoo/enterprise#95356 Forward-Port-Of: odoo/enterprise#93162
When warehouse staff split a package during barcode picking, the new split line now keeps the original reserved source package. This prevents package information from being lost and helps ensure partial deliveries remain accurate and traceable.
Original PR description
### Before this PR: - Put a package in WH/Stock with quantity 100 - Create delivery for partial quantity for example 50 - Go to app barcode - Try to split the package into two different packages scanning another destination Package - The splitted line will be created with empty package instead of the package already reserved before ### After this PR: Scanning another destination package , the new line created splitting the old one will have the package_id Forward-Port-Of: odoo/enterprise#91930 Forward-Port-Of: odoo/enterprise#81170
A unit test for Hong Kong payroll accounting was corrected after a public holiday work-entry reference was moved and renamed. This helps keep automated testing reliable, reducing the risk of payroll-related regressions reaching users.
Original PR description
Explanation: l10n_hk_hr_payroll.work_entry_type_public_holiday is moved to hr_work_entry and renamed as l10n_hk_work_entry_type_public_holiday runbot-229910