Daily updates from Odoo
Navigate
Branch
Friday, February 13, 2026
175 changes
37 changes
Resolved issues and error corrections
This update resolves an issue where the "Add to Cart" button in the product configurator would wrap awkwardly on smaller screens. The changes adjust the button's styling to ensure the text remains readable across different device sizes, improving the user experience and preventing a potential frustration for customers.
Original PR description
This commit fixes some text wrapping issues for the buttons inside the product configurator: - Change "Add to Cart" text visibility from d-md-inline to d-lg-inline for better mobile layout and prevent text wrapping - Add text-nowrap class to configurator's footer primary button to prevent text wrapping task-5896776 | Before | After | |--------|--------| | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/fa9106df-c8ee-4ade-a8ce-466549b8e816" /> | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/70de2a6a-b6d8-43da-bbdb-97e1b921078b" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248016
This update resolves a bug where users could create duplicate account codes, even for accounts that were previously archived. The fix now ensures that account codes are unique across both active and archived accounts, preventing data inconsistencies and improving data integrity. This ensures accurate financial reporting and reduces the risk of errors.
Original PR description
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#248439
This update corrects a formatting issue with preparation tickets printed from kiosks. Previously, the font size and product name display were inconsistent with the standard POS tickets. The fix aligns the kiosk ticket template with the POS module, ensuring consistent and accurate printing for improved customer experience.
Original PR description
Before this commit, preparation tickets printed from kiosk had a different structure from those printed from the POS. Two differences were spotted: 1. Font size was smaller than ticket printed from the pos 2. The name of the product displayed was the full product name instead of the basic one with attributes under the product name. So, to fix that I basically used the same template structure from the point_of_sale module and adapted data to fit with. task : 5506329 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245177
A previous issue prevented users with manufacturing rights from producing Manufacturing Orders, resulting in an access error. This fix ensures that users can now correctly produce orders without encountering this error, improving the usability of the manufacturing process. The change avoids unnecessary accounting record creation.
Original PR description
Issue before this commit: ========================= Clicking Produce All on a Manufacturing Order as a user with Manufacturing rights raised an Access Error. The button tried to create account.move…
Issue before this commit: ========================= Clicking Produce All on a Manufacturing Order as a user with Manufacturing rights raised an Access Error. The button tried to create account.move and account.move.line records, which the user had no permission to create. Steps to Reproduce: ========================= 1. Install account and mrp modules. 2. Create a product with: - Track Inventory enabled - Product uses real-time valuation - A cost of production exists on production/inventory location 3. Create a user with only Manufacturing user rights. 4. Log in as that user. 5. Create a Manufacturing Order, confirm it, and click Produce All. Cause of the Issue: ========================= Stock valuation during production attempted to create accounting entries for specific locations or analytics, but users lacked access to account.move and account.move.line, causing an access error. With This Commit: ========================= This commit allows users to produce Manufacturing Orders without changing the stock valuation logic. Steps to Reproduce: [Video Link](https://drive.google.com/file/d/1--k6m_UvoTyFpavPn1JUOyhsKydeMbVL/view?usp=sharing) opw-5487383 Forward-Port-Of: odoo/odoo#246038
This update fixes a visual issue in the Italian tax module where the TC-XX codes for pension funds weren't displayed alongside the fund names. The change ensures consistency with other selection fields, improving the clarity and usability of the Italian tax forms for users. This update was made to align with standard formatting practices.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update fixes an issue where anonymous users could bypass the address form during event ticket purchases, leading to incorrect tax calculations. The team adjusted a payment flow refactoring to ensure all users, including those registering for events without a billing address, are prompted for address details before proceeding to payment. This ensures accurate tax application and a smoother checkout experience.
Original PR description
**Steps to reproduce:** - Install Website/Event/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled - Publish…
**Steps to reproduce:** - Install Website/Event/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled - Publish the event - Register to the event as a anonymous user - The process bypasses the address form and goes directly to payment - The resulting sale order will have no fiscal position - Prices won't be impacted by taxes related to the user billing address **Issue:** Address form is skipped before payment for event registration of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit). **Fix:** Set `_needs_customer_address` to `True` by default to avoid such issues in dependant modules. Might need to remove this feature in master as the workarounds are not that clean (geo_ip, check on fiscal position enabled, overwrite everywhere, others ?). Similar fix is done for appointments with payment enabled. related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d original-task: https://www.odoo.com/odoo/project/49/tasks/4307281 opw-5143124 Forward-Port-Of: odoo/odoo#248291 Forward-Port-Of: odoo/odoo#247054
This update brings the latest version of the spreadsheet component to Odoo 19.1. It includes bug fixes related to chart.js integration and improvements to the spreadsheet's formatting functionality. These changes enhance the spreadsheet's performance and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f135c07860 [REL] 19.1.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f135c07860 [REL] 19.1.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/bd995244ef [FIX] side_panel: reset format type to Automatic on unformatted cells [Task: 5398649](https://www.odoo.com/odoo/2328/tasks/5398649) https://github.com/odoo/o-spreadsheet/commit/269cec2a56 [IMP] pivot: truncate dimension display name and add title [Task: 5895856](https://www.odoo.com/odoo/2328/tasks/5895856) https://github.com/odoo/o-spreadsheet/commit/f9152ea8d9 [FIX] Package: bump chart.js version [Task: 5925547](https://www.odoo.com/odoo/2328/tasks/5925547) https://github.com/odoo/o-spreadsheet/commit/ec718dfbbd [FIX] Chartjs: fix leak of chartJs lib in o-spreadsheet bundle [Task: 5925547](https://www.odoo.com/odoo/2328/tasks/5925547) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects a visual issue where installable snippet groups (like Blogs or Events) incorrectly displayed as "not droppable" when not installed. The fix ensures these groups are accurately shown as droppable, aligning with expected functionality and improving the user experience. This resolves a minor usability concern.
Original PR description
Since this commit [1], installable snippet groups like "Blogs" or "Events" are shown as “not droppable” on the page when they are not installed, which is incorrect. Installable snippet groups should never be marked as “not droppable” unless all groups are disabled (e.g. in the mega menu). This commit fixes that. [1]: https://github.com/odoo/odoo/commit/ae4824640665fc639e03a13c341f18e73060349e
This update fixes an issue where the names of products with variants were being duplicated on unvalidated delivery slips and backorders. The problem stemmed from how the system handles product descriptions when generating these reports. This change ensures accurate product naming across all delivery slip outputs.
Original PR description
When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated. ### Steps to reproduce: * Create a product A with variants of type…
When creating a delivery slip, if the product sold has variant of type never and have a description, the name will be repeated. ### Steps to reproduce: * Create a product A with variants of type never * Create a sales order with two product A and confirm it * Go on the delivery (don't validate it) and create a delivery slip -> Issue, the name of the product appears twice. * Reduce the quantity of product delivered to one * Confirm and create a backorder * Print the deliveryslip -> Issue, the name of the product appears twice in the backorder section ### Observation: When confirming the SO: It creates the procurement values, where the product_description_variants are obtained from _get_sale_order_line_multiline_description_variants. In our case, we will have several elements regarding the variant: https://github.com/odoo/odoo/blob/3e5aabf66a19d406fa49c9ff2f6e4db6d5ba124a/addons/sale_stock/models/sale_order_line.py#L300 This information is added to the picking_description (for which the fallback value is the product name): https://github.com/odoo/odoo/blob/626d06734991bcd3b94a6c9454317f311164e9dc/addons/stock/models/stock_rule.py#L339-L340 When printing the delivery_slip, it uses description_picking (and attempts to filter out the name): https://github.com/odoo/odoo/blob/842025976ab65e92551366def88cdd243549e5ee/addons/stock/report/report_deliveryslip.xml#L74 However, in our case, since the variant information is included, it will not be filtered out because the value is no longer just the name. The same issue is present here : https://github.com/odoo/odoo/blob/e99e07f2f22b0987468c45d3d7da287cdf703588/addons/stock/report/report_deliveryslip.xml#L179-L180 opw-5153222 Forward-Port-Of: odoo/odoo#247610 Forward-Port-Of: odoo/odoo#239693
This update resolves an issue where comments within XML invoices, specifically added to the TaxExclusiveAmount field, were causing the system to fail to recognize and process the invoices. The fix removes these comments during the XML parsing process, ensuring invoices are correctly uploaded and processed. This prevents empty invoices from being created.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
The website editor's snippet preview was displaying incorrectly due to a CSS loading issue. This update ensures that the preview height is accurately calculated by loading CSS before JavaScript, resolving a visual discrepancy. This improves the user experience when designing website content.
Original PR description
Steps to reproduce: - Open the website editor. - Open the snippet dialog. - Look at a carousel snippet preview. => The preview height is too tall. Before this commit, the dialog loads CSS after JS, so "computeMaxHeight" ran on an unstyled DOM and missed the "fit-content" height for the carousel. After this commit, the preview forces "fit-content" in JS so the height matches the final CSS layout. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244295 must be present** Forward-Port-Of: odoo/odoo#248175 Forward-Port-Of: odoo/odoo#244662
This update fixes a problem where the self-order page would freeze if local data was corrupted. Now, users receive an error message with the option to clear their data and refresh, particularly helpful on mobile devices. This enhances usability and prevents frustrating user experiences.
Original PR description
Inconsistent data in the localDB or local storage can cause the pos_self_rder to fail before it can get initialized. When this happens the page just stays white. Now when an error happens while initializing an error message will show up and give the user the option to clear all local data and refresh the page. This should be especially useful for users on mobile where it's a pain to refresh the local data manually. Task-[5420544](https://www.odoo.com/odoo/project/1737/tasks/5420544) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247167 Forward-Port-Of: odoo/odoo#246925
This update ensures that UBL BIS3 files generated by our accounting module are valid according to PEPPOL standards. Previously, files lacking an EndpointID were automatically rejected. This change adds necessary validation within Odoo itself, streamlining the process and preventing errors.
Original PR description
If EndpointID is not set, the generated file is invalid due to the 2 following rules: [PEPPOL-EN16931-R010] Buyer electronic address MUST be provided. [PEPPOL-EN16931-R020] Seller electronic address MUST be provided. Since this is a configuration issue, there is no point of sending such files to be rejected right away. Instead, let's add those 2 contraints ODOO-side. task-5890887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248321 Forward-Port-Of: odoo/odoo#246961
This update resolves an issue where course sections were incorrectly being converted to document slides. The fix addresses a removal of a field used by the website_slides widget, and ensures sections are created as intended. This improves the user experience when creating and managing course content.
Original PR description
Steps: - Install `website_slides` - Edit a course - Add a section in the slides - Save - Section is automatically changed into document slide The problem stems from the fact that the widget that…
Steps:
- Install `website_slides`
- Edit a course
- Add a section in the slides
- Save
- Section is automatically changed into document slide
The problem stems from the fact that the widget that manages sections in website_slides uses the `is_category` field to function (display certain fields in the list view).
However, this `is_category` field has been removed since saas-19.1 in the following [diff](https://github.com/odoo/odoo/pull/230098/changes#diff-87985c6cb54c5ab6dd4b71da844d0478e70c3c8247d54c943113ba75a4af0188L85 )
with a view to getting rid of invisible fields in views and adding them automatically in `ir_ui_view`.
But in `IrUiView::_add_missing_fields`, this field is added as read-only.
https://github.com/odoo/odoo/blob/02af5899563ddc362d04522339a5bdb793e01b52/odoo/addons/base/models/ir_ui_view.py#L1530-L1545
On the client side, when saving a `web_save` is performed by omitting `is_category`, because we are not supposed to save/write read-only fields.
Since the field has a default value of false, we end up with a slide that is not a section
```py
is_category = fields.Boolean(`Is a category`, default=False)
```
To fix this problem, we directly correct `slide_category_one2many` which uses is_category without ever checking that the field is available by adding a relatedFields that specifies that we need is_category and not readonly.
Note: we have exactly the same problem with section_and_note in the `account` module, which uses the `display_type` field, but here it works because in its view we kept the field when deleting all invisible fields.
https://github.com/odoo/odoo/blob/8128a1bfbdd7b2f7cdc8ccbf1ddf78219a809e38/addons/sale/views/sale_order_views.xml#L568-L569
opw-5898399This update fixes a technical error that could cause the Odoo system to crash when a Contact ImageField was empty. The change ensures the system handles missing image data gracefully, improving stability and preventing disruptions to user workflows. This resolves a minor issue impacting contact management functionality.
Original PR description
Steps to reproduce ================== - Go to contacts - Open studio - Switch to the form view - Open the x2many form view => TypeError: Cannot read properties of undefined (reading '0') opw-5885953
This update ensures Odoo can consistently connect to printers by defaulting to a more modern printing protocol (IPP Everywhere) when a standard printer profile isn't available. This resolves compatibility issues with older printer models, enhancing the overall printing experience. The change primarily affects the IoT drivers module.
Original PR description
When no `ppd` is available for the cups discovered printer, we now use the IPP Everywhere ppd. We only set it for dnssd printers as printer that only implement socket/lpd could be too old and not compatible with IPP Everywhere. Forward-Port-Of: odoo/odoo#247210
This update fixes a potential issue in the Point of Sale (POS) system where rounding calculations weren't always accurate with cash payments. This meant orders could sometimes be incorrectly validated, leading to discrepancies between the amount paid and the rounded total. This change ensures more reliable and accurate order processing within the POS.
Original PR description
When using rounding methods in POS with cash payments, the applied rounding was not being calculated correctly in some edge cases, leading to situations where the order could be validated even when the amount paid did not match the rounded total. opw-5460460 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242068
This update corrects a bug in the Point of Sale system where orders weren't properly validated when payments were incomplete. Previously, the system would continue processing orders even without full payment, leading to potential double-entry errors and data inconsistencies. This fix ensures that orders remain in the correct 'draft' state until fully paid, maintaining data accuracy.
Original PR description
After commit https://github.com/odoo/odoo/commit/dde26e5372b8328bbc9e050f0fdedadd1de649fd, when trying to validate a POS order that was not fully paid, the order state would remain in 'draft' state but the picking and other related operations would be done. This could lead to double entries and inconsistencies. opw-5447749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244542
This update resolves a problem where invoices created after reversing a Point of Sale (PoS) order wouldn't properly reconcile, leading to incorrect credit balances. The fix automatically links the reversal entry to the original customer account payment, ensuring only the invoice remains open and accurate. This improves financial reporting and reduces potential discrepancies.
Original PR description
If you made a PoS order paid with the customer account payment method, then close the session. Then invoice the order, a reversal entry would be created but it would not be reconciled at all. As no payment was made a this point it should be reconciled with the original Customer Account entry from the pos session, this way only the invoice remains open. Steps to reproduce: ------------------- * Create a PoS order and pay with the customer account payment method * Close the session * Go on the order and create the invoice > Observation: The reversal move is not reconciled and the customer has two outstanding credits. Why the fix: ------------ When creating the invoice we reconcile the reversal entry with the original customer account entry from the pos session. This way only the invoice remains open. opw-5268042 Forward-Port-Of: odoo/odoo#245941
This update resolves a 1-second delay that occurred when reading data from Toledo scales. The change improved the system's responsiveness by switching to a method that detects the end of the scale response, rather than waiting for a timeout. This ensures more accurate and timely data collection.
Original PR description
Before this commit, the `_get_raw_response` method would wait until the read timed out (1 second) before returning the response. After this commit, for the Toledo scale we instead read until we reach a `\r` character, which is at the end of the response. This eliminates the 1 second delay. Enterprise PR: https://github.com/odoo/enterprise/pull/107246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248416
This update resolves an issue where the 'Group by category' option in Point of Sale was not displaying all products correctly. The change utilizes a more reliable method to group products by category, ensuring a complete and accurate product list is presented to users. This improves the user experience and accuracy of sales transactions.
Original PR description
Before this commit when activating the "Group by category" option in the POS, some products were missing from the product list. Now we use the `getAllBy` generic model method to group products by category, which ensures that all products are correctly grouped and displayed in the POS. Forward-Port-Of: odoo/odoo#247782
This update resolves a rare issue where the popover animation in our tests ran too quickly, leading to unexpected behavior. By adjusting the animation timing, we've ensured tests are more reliable and consistent, preventing potential disruptions in the system. This improves the overall stability of the web application.
Original PR description
Because the popover had his animation enabled in tests, it could in very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247341 Forward-Port-Of: odoo/odoo#244491
This update fixes a bug where combo product prices weren't calculated accurately when a combo didn't include a free item. Previously, the total price was incorrect. This change ensures that combo prices are now calculated correctly, providing more accurate sales totals.
Original PR description
If a combo product is configured with no free item, the parent product's price was not computed in total correctly. opw-5241225 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234766
This update ensures that all attachments – like invoices and PDFs – are now included in the email notifications sent when importing invoices or vendor bills. Previously, only the first attachment was displayed, leading to missed documents. Additionally, users will now manually specify recipients for copy emails, simplifying the process.
Original PR description
Before this PR, when importing an invoice or vendor bill, the email notification only included the first imported attachment. As a result, embedded files (e.g. a PDF inside an XML) were missing from the email. This commit ensures that all imported attachments are included in the notification email, improving document visibility for users. Additionally, the field "Send Copy To" will no longer be computed, It'll be manually filled by the user. task-5895328 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246936
This update resolves an issue where creating a new warehouse would fail if the required 'Inventory Loss' stock location wasn't present. The fix now displays a user-friendly error message, guiding users to add the necessary location before proceeding with warehouse creation. This prevents data inconsistencies and ensures smooth warehouse setup.
Original PR description
Currently, an error occurs when user tries to create a new warehouse when Inventory loss stock location is not present. Steps to replicate: - Install repairs and enable Storage Locations in settings.…
Currently, an error occurs when user tries to create a new warehouse when Inventory loss stock location is not present.
Steps to replicate:
- Install repairs and enable Storage Locations in settings.
- Go to `Inventory > Configuration > Locations`, open `Inventory Adjustment`.
- Change the `Location Type` to `Internal` (anything other than `Inventory Loss`).
- Navigate to Warehouses and try to create a new one.
Error:
```
File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 142, in create
new_vals = warehouse._create_or_update_sequences_and_picking_types()
File /home/odoo/src/odoo/19.0/addons/stock/models/stock_warehouse.py, line 373, in _create_or_update_sequences_and_picking_types
create_data, max_sequence = self._get_picking_type_create_values(max_sequence)
File /home/odoo/src/odoo/19.0/addons/repair/models/stock_warehouse.py, line 30, in _get_picking_type_create_values
scrap_location_id = self.env['stock.location'].search_read([('usage', '=', 'inventory'), ('company_id', 'in', [self.company_id.id, False])], fields=['id'], limit=1)[0].get('id')
IndexError: list index out of range
```
Cause:
- Since the user changed the location type of `Inventory adjustment`, the `search_read()` [1] returned no results and attempting to access its first element causes the error.
Solution:
- Raised a UserError when no Inventory Loss location is found while warehouse creation.
[1]: https://github.com/odoo/odoo/blob/62b9f7a81e8d742508d6c80434bb4caf78f9dc65/addons/repair/models/stock_warehouse.py#L30
sentry-7169389190
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242535This update resolves a bug where serial numbers weren't correctly generated when creating multiple serials in subcontracted manufacturing orders. Specifically, interpolated prefixes weren't being applied, leading to duplicate serial numbers. The fix ensures that serial numbers use the correct, interpolated values, preventing this issue and ensuring accurate tracking of products.
Original PR description
## Issue When generating multiple serial numbers in a single manufacturing order, interpolations are not replaced. For example, if the sequence prefix is `%(month)s`, the placeholder is not be…
## Issue
When generating multiple serial numbers in a single manufacturing order, interpolations are not replaced. For example, if the sequence prefix is `%(month)s`, the placeholder is not be replaced by the current month, and the generated serial numbers contain `%(month)s` literally.
This issue also impacts the `mrp_subcontracting` serial numbers generation by causing a similar issue as the second bug described by https://github.com/odoo/odoo/commit/20158a1. When creating a duplicate of a subcontracted manufacturing order, the *First SN* field (`lot_name`) is initiated to `1` again, instead of starting from the last SN of the previous MO. This issue was supposedly fixed by https://github.com/odoo/odoo/commit/9cd0c4a, but the issue still occurs when using interpolated prefix.
## Steps to reproduce
1. Install *Manufacturing* (`mrp`)
2. In Settings, enable *Lots & Serial Numbers*
3. In Settings > Technical > Sequences, give a prefix using interpolation to the `stock.lot.serial` sequence. An example of such prefix could be `%(year)s-%(month)s-%(day)s-`
3. Create a product P
- Tracked *By Unique Serial Number*
- Create a BoM for the product P
4. Create and confirm a Manufacturing Order for product P
- Quantity >= 2
5. Click *Generate Serial*
6. **The _First SN_ field uses the interpolation without replacing the placeholders. When clicking _Generate_, more serials are generated where the placeholders are not replaced. If we proceed, the produced serial numbers still contain the placeholders.**
If we generate a MO with a quantity of one, the serial number is correctly generated (the placeholders are replaced as expected).
## Cause
The method responsible for replacing the interpolation placeholder is `IrSequence._get_prefix_suffix` which is called by `IrSequence.get_next_char`:
https://github.com/odoo/odoo/blob/bf7dee8069f203095c44381708153865d3e8f19e/odoo/addons/base/models/ir_sequence.py#L240-L242
Generating a single serial numbers work as expected because it calls `MrpProduction.action_generate_serial`, which uses `IrSequence.get_next_char` further down the call stack.
When generating **multiple** serial numbers in a single MO, the [`mrp.production.serials` wizard](https://github.com/odoo/odoo/blob/19.0/addons/mrp/wizard/mrp_production_serial_numbers.py) is used. In this flow, `get_next_char` is never called, because the serial number logic is reimplemented using fields (`serial_prefix_format` and `next_serial`) from the `product.product` model.
## Fix
Serial numbers are generated from the *First SN* (`lot_name`) field. Correctly applying the interpolation to that field ensures that all subsequently generated serial numbers also use the interpolated values. Because `mrp_subcontracting` inherits the behavior from `mrp` to generate the lot_name, fixing this issue in `mrp` also solves it in `mrp_subcontracting`.
When initiating the `lot_name` field, we need to take in account cases where the product does not have a `lot_sequence_id`. This can happen if the sequence of the product was deleted. The same check is not required when updating the `number_next_actual`, as if there's no `lot_sequence_id`, there's no `number_next_actual` to update.
The logic updating the `number_next_actual` has also been adjusted to ensure the field is incremented correctly. This was an issue corrected by https://github.com/odoo/odoo/commit/20158a115ef3dfb9fe2dd5103d3bed7e87e37940 and https://github.com/odoo/odoo/commit/3ff0f2e3ef4fbcbf0b0b0ae6db8ff6f52bfdf67a, but without taking interpolated prefixes into account.
opw-5882578
Forward-Port-Of: odoo/odoo#246762This update streamlines the testing process for the website slides module. The change removes unnecessary code related to a previous update, simplifying the tests and ensuring consistent functionality. This improves the overall stability and efficiency of the website slides feature.
Original PR description
Since https://github.com/odoo/odoo/pull/248480 there is no need to add `is_category` in the view with `invisible='1'`
This update temporarily pauses automatic updates to the IoT box drivers to ensure compatibility with the upcoming saas-19.2 release. This prevents potential disruptions to existing systems and allows for thorough testing before the new code is deployed. Updates will resume once saas-19.2 is confirmed to work seamlessly with all stable versions.
Original PR description
This PR temporarily blocks the automatic iot boxes update for upcoming saas-19.2 to unlbock it only after ensuring saas-19.2 iot box code compatible with all stable versions
This update fixes an issue where the toolbar wasn't visible when triple-clicking on text with icons in the Email Marketing module. The fix ensures proper text selection and toolbar display, improving the user experience when editing comparison snippets. This resolves a visual bug impacting functionality.
Original PR description
Problem: When triple-clicking on text inside a list item that contains an icon, the toolbar is not shown. Cause: The toolbar is not displayed when the selection anchor node is inside an element with…
Problem: When triple-clicking on text inside a list item that contains an icon, the toolbar is not shown. Cause: The toolbar is not displayed when the selection anchor node is inside an element with `contenteditable="false"`. This happens in cases like: `<li><span class="…" contenteditable="false"></span>abc</li>` When triple-clicking on "abc", the selection anchorNode becomes the `span` and the offset is `0` and offset is "abc" offset 3. In that case, `selection.toString()` returns an empty string. While this may also be a browser related issue as the selection includes text but `toString()` still returns empty string, the root cause here is that normalization does not wrap the icon with `feff` because the corresponding selector is missing. Solution: Include icons under `li` elements when wrapping nodes with `feff`, so the selection is normalized correctly and the toolbar can be shown. Steps to reproduce: - Open Email Marketing. - Drop the "Comparison" snippet. - Triple-click on one of the texts with check icons. - Observe that the toolbar is not shown. task-5913202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248513 Forward-Port-Of: odoo/odoo#247582
This update prevents users from creating new lot/serial numbers directly from the Contacts app. Previously, this unintended feature led to inconsistent data. This fix hides the 'New' button, ensuring data integrity until a proper creation flow is implemented.
Original PR description
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts`…
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts` modules. - Enable `Lots & Serial Numbers` from the inventory settings. - Open the `Contacts` app and open any contact record. - Click the `Lots/Serial Numbers` smart button. **Observation:** The user can `create` a new lot/serial number from the Contacts, even though this flow is not supported and results in inconsistent data. **Root cause:** After PR [1], `lot/serial number` creation was accidentally enabled from the Contact. The intended behavior is that Contacts should only be able to view related lots/serial numbers, not create them. (Confirm with PO `crl`) **Fix:** This commit disables the creation of Lot/Serial Numbers from the contact by `hiding` the New button. This prevents users from creating inconsistent records until a complete and correct flow is implemented in a future improvement as mentioned at [2]. [1]: https://github.com/odoo/odoo/pull/184242 [2]: https://www.odoo.com/mail/message/978482657 opw-5504073 Forward-Port-Of: odoo/odoo#245426
This update resolves two errors in the Hong Kong payroll calculations. Specifically, it corrects a mistake where rental allowances were incorrectly included in IRD reports and removes an incorrect deduction of ERMPF from taxable salaries. These changes ensure accurate reporting and compliance with Hong Kong tax regulations.
Original PR description
Fixes two issues related to computations; The taxable salary wrongly deduce the ERMPF which it should not. in the IRD reports, the total income includes the rental allowances, which is wrong according to their specs. task-5353781 Forward-Port-Of: odoo/enterprise#107219 Forward-Port-Of: odoo/enterprise#100842
This update resolves an issue where the project_enterprise_hr module was failing to load due to a missing dependency on the project_todo template. Adding project_todo as a dependency ensures that all necessary templates are available, preventing errors and maintaining module functionality. This ensures proper onboarding workflows.
Original PR description
The module project_enterprise_hr inherits the template project_todo.todo_user_onboarding.(#97345) Since project_todo was not declared as a dependency, it could be installed or uninstalled at the time…
The module project_enterprise_hr inherits the template project_todo.todo_user_onboarding.(#97345)
Since project_todo was not declared as a dependency, it could be installed or uninstalled at the time of migration, which caused an `External ID not found` error during module loading.
To resolve this issue, the project_todo module has been added to the dependencies
to ensure the inherited template is always available.
Traceback
```sql
2026-02-06 17:46:11,615 26 INFO db_3885064 odoo.modules.loading: loading project_enterprise_hr/data/todo_template.xml
2026-02-06 17:46:11,620 26 WARNING db_3885064 odoo.modules.loading: Transient module states were reset
2026-02-06 17:46:11,620 26 ERROR db_3885064 odoo.registry: Failed to load registry
2026-02-06 17:46:11,620 26 CRITICAL db_3885064 odoo.service.server: Failed to initialize database `db_3885064`.
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 621, in _tag_root
f(rec)
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 559, in _tag_template
return self._tag_record(record)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 436, in _tag_record
f_val = self.id_get(f_ref, raise_if_not_found=nodeattr2bool(rec, 'forcecreate', True))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 605, in id_get
return self.model_id_get(id_str, raise_if_not_found)[1]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 609, in model_id_get
return self.env['ir.model.data']._xmlid_to_res_model_res_id(id_str, raise_if_not_found=raise_if_not_found)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/ir_model.py", line 2260, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/cache.py", line 87, in lookup
return self.lookup(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/cache.py", line 140, in lookup
value = self.method(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/addons/base/models/ir_model.py", line 2253, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: project_todo.todo_user_onboarding
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.1/odoo/service/server.py", line 1519, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/func.py", line 68, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.1/odoo/orm/registry.py", line 202, in new
load_modules(
File "/home/odoo/src/odoo/saas-19.1/odoo/modules/loading.py", line 457, in load_modules
load_module_graph(
File "/home/odoo/src/odoo/saas-19.1/odoo/modules/loading.py", line 217, in load_module_graph
load_data(env, idref, mode, kind='data', package=package)
File "/home/odoo/src/odoo/saas-19.1/odoo/modules/loading.py", line 59, in load_data
convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 709, in convert_file
convert_xml_import(env, module, fp, idref, mode, noupdate)
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 808, in convert_xml_import
obj.parse(doc.getroot())
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 679, in parse
self._tag_root(de)
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 621, in _tag_root
f(rec)
File "/home/odoo/src/odoo/saas-19.1/odoo/tools/convert.py", line 634, in _tag_root
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing None:5, somewhere inside
<data>
<xpath expr="//t[@name='shortcut_section']" position="before">
<t t-if="object.company_id.alias_domain_id">
<t t-set="alias" t-value="object.env.ref('project_enterprise_hr.mail_alias_todo', raise_if_not_found=False)"/>
<t t-if="alias">
<h3>Create To-Dos by Email</h3>
<hr/>
<p>
<span style="font-size: 14px;">
<t t-set="alias_email" t-value="'%s@%s' % (alias.alias_name, object.company_id.alias_domain_id.name)"/>
Send an email to <a t-att-href="'mailto:%s' % alias_email"><t t-out="alias_email"/></a> to create a to-do for yourself.
<br/>
Want to include others? Add their email addresses in the <strong>To</strong> field — they'll be added as assignees.
</span>
</p>
<p><br/></p>
</t>
</t>
</xpath>
</data>
```
opw-5904632
tbg-2442This update corrects a reporting issue where assets marked as disposed still appeared in depreciation schedules. The fix ensures that disposal dates are correctly calculated, preventing inaccurate reporting after an asset has been written off. This improves the reliability of financial reporting.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Audit Trail" - Go to "Accounting / Accounting / Management / Assets" - Create an asset: * Original Value: [any] * Acquisition Date: [in the past] (e.g. 01/01/2025) * Duration: [at least until today] (e.g. 36 Months) * Depreciation Account: [any] * Expense Account: [any] - Confirm the asset - Modify Depreciation: * Action: Dispose * Date: [in the past] (e.g. 30/10/2025) * Loss Account: [any] - Dispose - Go to "Accounting / Reporting / Management / Depreciation Schedule" - Filter on a period after the disposal date **Issue:** The asset appears in the selected period even if it has already been disposed. **Cause:** There are posted depreciation moves that have a date after the disposal date. These moves should be deleted but the Audit Trail feature prevents it. These moves are cancelled instead. However, the disposal date computed on the asset is taking the max date from all the depreciation moves. Even the cancelled ones ; leading to a disposal date different than the one entered. opw-5225749 Forward-Port-Of: odoo/enterprise#107028
This update fixes an issue where the 'Back to Production' button in the Product Catalog, accessed from the Shop Floor, incorrectly navigated users to the Manufacturing Order form. The change now correctly redirects users back to the Shop Floor, ensuring a smoother user experience when adding components to work orders.
Original PR description
Before this commit: ==================== When opening the product catalog from shop floor, the Back button is labeled “Back to Production” and navigates the users to Manufacturing Order(MO) form view…
Before this commit: ==================== When opening the product catalog from shop floor, the Back button is labeled “Back to Production” and navigates the users to Manufacturing Order(MO) form view instead of returning to Shop Floor. Steps to Reproduce: ==================== 1. Install `mrp_workorder` module. 2. Create a MO → Open it in `ShopFloor` → Open the Product Catalog to add a component to the MO. 3. Click on `Back to Production`. It will redirect to MO form view. Cause of the issue: ==================== The `backToQuotation` method in `ProductCatalogKanbanController` redirects the user back using breadcrumbs, and when no breadcrumbs exist, it falls back to opening the form view. Since the catalog is opened from the Shop Floor without any breadcrumbs, the user is always redirected to the MO form view. After this commit:- ==================== These changes rename the back button to `Back to Shop Floor` and ensure it redirects users to the Shop Floor when the catalog is opened from there. TaskID-5355924 Forward-Port-Of: odoo/enterprise#101331
This update fixes an issue where the dark mode wasn't correctly applied to the account search dialog within the Enterprise module. The change ensures a consistent dark mode experience for users, improving the overall user interface and visual appeal. This enhancement aligns with our commitment to providing a modern and accessible user experience.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/e3dec031033eeefb2b2271be6b0b6fbda3cf5bf0 the dark mode was not rightly supported. task-5932352 Forward-Port-Of: odoo/enterprise#107245
This update corrects a previous issue where importing journal items onto archived accounts would inadvertently create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and avoids potential accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765 Forward-Port-Of: odoo/enterprise#106962
A recent issue preventing the sign tour from completing has been fixed. The tour incorrectly identified a signer, leading to a failure. This update simply corrects a naming discrepancy within the system, ensuring the tour runs smoothly.
Original PR description
When running the sign_tour in 19.1 and master, the tour fails because during the selection of the signer we select the child that contains Administrator, but the name of the user is Mitchell Admin. Therefore the fix is as easy as modifying Administrator to Admin. Runbot Error: 238784
4 changes
Resolved issues and error corrections
The infinite scrolling feature for VoIP call history was temporarily broken in Chrome. This fix resolves the issue by addressing a technical problem with how the software detects the end of the scrolling list, ensuring all calls are now displayed correctly. This improves the user experience for managing VoIP calls.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106658
This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The change adjusts the allowed date range to align with Colombian regulations, ensuring invoices are processed correctly and avoiding unnecessary errors.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107255 Forward-Port-Of: odoo/enterprise#105763
This update corrects a previous issue where importing journal items onto archived accounts would inadvertently create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and prevents accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765 Forward-Port-Of: odoo/enterprise#106962
This update resolves a visual bug where the total time on the timesheet list view wasn't correctly formatted after a refresh. The fix ensures that the total time is displayed as a time value, matching the format of individual timesheet entries. This improves the user experience and accuracy of timesheet reporting.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
15 changes
Resolved issues and error corrections
This update resolves an issue where duplicate account codes could be created, even for archived accounts. Previously, the system only checked active accounts for uniqueness, leading to potential data inconsistencies. Now, the system validates account codes against both active and archived accounts, ensuring data integrity and preventing errors.
Original PR description
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
This update resolves a technical issue that caused the Odoo application to crash when using the Ukrainian language. The fix ensures that the application gracefully handles missing data patterns from CLDR, preventing errors and improving stability for users in this region. This change focuses on internal application performance.
Original PR description
**Steps to Reproduce:** 1. Install `stock_fleet` module (with demo data). 2. Set the **Ukrainian** language for the user. 3. Open Fleet > Vehicle > Click Category Error: `KeyError: '2'` **Cause:** Babel's CLDR list patterns for some locales (e.g., Ukrainian 'unit-short') do not include the two-item pattern key, so when babel's `format_list` attempts to access patterns, it will raise an error. **Fix:** This commit wraps the call in a try/except that handles KeyError and retries formatting with the 'standard' style to avoid the crash. Forward-Port-Of: odoo/odoo#248228
This update fixes a crash that occurred when creating vendor bills with multiple purchase orders linked through the autocomplete field. The issue stemmed from an error in how Odoo tracked record IDs during data insertion, leading to duplicate key errors. By limiting the number of linked purchase orders, this change ensures stable bill creation.
Original PR description
Steps to reproduce ================== - Edit the Vendor Bill form view to set a limit of 2 on the invoice_line_ids field. - Create 2 purchase orders with the same vendor and 4 products - Create a vendor bill - Set the same vendor - Using the autocomplete field, select the first purchase order - Save the form - Select the other purchase order in the autocomplete field - Delete the record before the last one => Got duplicate key in t-foreach: datapoint_12 Cause of the issue ================== Before inserting the last 4 lines: `this._currentIds = [1, 2, 3, 4]` After the second insert, we have `this._currentIds = [1, 2, virtual_1, 3, virtual 2, virtual_3, virtual_4, 4]` Only the first record is inserted at the correct place, following ones are off by one. opw-5264594 Forward-Port-Of: odoo/odoo#248451
This update corrects a visual issue in the Italian tax module (l10n_it_edi) where TC-XX codes weren't displayed alongside pension fund type names. The fix ensures consistency with other selection fields, improving clarity and usability for Italian businesses using the Odoo accounting system.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update resolves an issue where comments within invoice XML files, specifically added during Peppol transmission, were causing the system to fail to recognize invoices. The fix removes these comments during XML parsing, ensuring invoices are correctly processed and uploaded. This prevents empty invoices from being created.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
This update corrects a rare display problem in Firefox where the HTML editor would create duplicate buttons and links with unexpected text placement. The fix resets the browser's internal state related to links, ensuring proper button and link rendering across different browsers. This improves the overall user experience within the HTML editor.
Original PR description
In some situations Firefox behaves strangely when adding a character add the end of a button, by duplicating the button element without children and inserting the text between both buttons. It seems Firefox maintains an internal selection state that is corrupted after some operations. This commit resets the collapsed selection inside links in order to reset this internal state in Firefox. Steps to reproduce: - Insert a link - Put some text after the link - Delete the first character from the text - Keep deleting until the last character from the button is deleted - Type a character => The button was duplicated and the text was inserted between both buttons. - Note that if you undo/redo, then typing a character did work fine task-5033890 Forward-Port-Of: odoo/odoo#241895
This update fixes several issues related to how website snippets are displayed in the editor. Specifically, it ensures carousel preview heights are consistent, parallax previews now correctly show zoom effects, and custom snippet labels are properly displayed. These changes enhance the user experience and accuracy of the website editor.
Original PR description
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet…
Steps to reproduce: - Open the website editor. - Add a carousel snippet to a page. - Remove content from the first slide so it is shorter. - Save the carousel as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview height is too small. Before this commit, the preview height was computed from the scaled size, so shorter slides made the preview min-height too low. After this commit, the preview height uses the layout size so the min-height stays consistent with other slides. ---------- Steps to reproduce: - Open the website editor. - Open the snippet dialog and resize the window. => The parallax preview background shifts to the left. - Save a snippet with a parallax zoom in/out effect as a custom snippet. - Open the snippet dialog and locate the custom snippet. => The preview shows a top to bottom effect instead of zoom. Before this commit, resizing the snippet dialog could offset the parallax background to the left, and zoom previews looked like top to bottom effects. After this commit, the preview keeps the background aligned and shows zoom in/out effects for custom snippets. Fixed parallax is still not previewed because it would require an oversized background in the dialog. ---------- Steps to reproduce: - Open the website editor. - Save a "Carousel" snippet as a custom snippet. - Open the snippet dialog. => The custom snippet shows no label. Before this commit, custom previews dropped the base label so the dialog showed no tag for custom snippets. After this commit, custom previews reuse the base label. task-5156137 **To see/test the bug, the change made in https://github.com/odoo/odoo/pull/244251 must be present**
This update prevents users from creating new lot/serial numbers directly from the Contacts app. Previously, this unintended feature led to inconsistent data. The fix hides the 'New' button, ensuring data integrity until a proper creation flow is implemented.
Original PR description
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts`…
Currently, users can `create` new `Lots/Serial Numbers` directly from the Contacts app via the `Lots/Serial Numbers` smart button. **Steps to reproduce:** - Install the `stock` and `contacts` modules. - Enable `Lots & Serial Numbers` from the inventory settings. - Open the `Contacts` app and open any contact record. - Click the `Lots/Serial Numbers` smart button. **Observation:** The user can `create` a new lot/serial number from the Contacts, even though this flow is not supported and results in inconsistent data. **Root cause:** After PR [1], `lot/serial number` creation was accidentally enabled from the Contact. The intended behavior is that Contacts should only be able to view related lots/serial numbers, not create them. (Confirm with PO `crl`) **Fix:** This commit disables the creation of Lot/Serial Numbers from the contact by `hiding` the New button. This prevents users from creating inconsistent records until a complete and correct flow is implemented in a future improvement as mentioned at [2]. [1]: https://github.com/odoo/odoo/pull/184242 [2]: https://www.odoo.com/mail/message/978482657 opw-5504073
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the POS experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244103 Forward-Port-Of: odoo/odoo#241373
This update fixes an issue where invoices created in foreign currency didn't accurately display the amount in the company's local currency when generating reports. The fix ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for SA companies. This improves the reliability of financial data.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. 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#245840
This update fixes a bug where empty loyalty cards were created when not all loyalty programs applied points to an order. Now, loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data cleanliness. This ensures accurate loyalty program tracking.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#247491 Forward-Port-Of: odoo/odoo#244254
This update corrects a previous issue where importing journal entries onto archived accounts would inadvertently create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and avoids potential accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765
This update fixes an issue where invoices sent to DIAN or Carvajal were incorrectly flagged with a warning if the invoice date was within a specific range. The change adjusts the date validation to align with Colombian regulations, allowing for invoice dates up to 6 days before and after the current date, ensuring accurate electronic invoicing.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid.…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN` or `Carvajal`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to reproduce:** - Install the `l10n_co_dian` module and switch to the `CO company`. - Go to `Invoicing` and create a new invoice with `taxes`. - Set the `Invoice Date` to 6 days before today. - Click `Confirm` > `Send`, ensure `DIAN` is selected, and `send` the invoice. - Observe the warning message. **Observation:** `The issue date can not be older than 5 days or more than 5 days in the future.` **Root cause:** At [1] and [2], the allowed invoice date range is incorrectly computed, using `5 days in the past` and `10 days in the future`. This does not match the Colombian regulations and triggers incorrect validation errors for valid invoice dates. These checks are intentionally implemented in both modules because they apply at different stages and for different providers: 1) `l10n_co_dian` When `DIAN: Free service` is selected as the `Electronic Invoicing Provider` from the `Invoicing Settings`, the date constraint is evaluated at `send time`. After the invoice is created, the validation is performed when the user sends the invoice to `DIAN`, and a blocking error is raised as a `UserError` if the invoice date is outside the allowed range. 2) `l10n_co_edi` When `Carvajal` is selected as the `Electronic Invoicing Provider`, the same rule is checked `at the confirmation time` of the draft invoice. In this case, the validation results in a `chatter message`, not a blocking send-time error. **Fix:** This commit updates the date constraint logic to allow invoices dated up to `6 days before and 6 days after` the current date, in accordance with the DIAN specification described in Anexo Técnico – Documento Soporte No Obligados, page 59, at [3]. <img width="1089" height="120" alt="DIAN" src="https://github.com/user-attachments/assets/408c5ccc-5fed-4585-a81e-dce4ccb98b40" /> [1]: https://github.com/odoo/enterprise/blob/2217827c0989fc5fc8d52a6a9b6f6c6d00b9773f/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L672-L679 [2]: https://github.com/odoo/enterprise/blob/913e55abc4a9aa58509aa2a60d378fb552de554d/l10n_co_edi/models/account_edi_format.py#L574-L603 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107255 Forward-Port-Of: odoo/enterprise#105763
This update fixes an issue where the total time on timesheets displayed in the list view was incorrectly formatted as a regular number instead of a time. The fix ensures that the total is always displayed in the correct time format, regardless of page refreshes. This improves the accuracy and usability of timesheet reporting.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
This update corrects a UI issue where the partner name incorrectly remained displayed on bank statement lines after removing a partner from the bank reconciliation widget. The fix uses a direct database update to clear the partner name field, ensuring the UI accurately reflects the current partner information. This improves the user experience and data accuracy.
Original PR description
When a user removes the partner from the liquidity line in the bank reconciliation widget, the 'partner_name' field on the statement line is not cleared. This results in the UI displaying the old name even though the partner is removed. in the first time i wanted to fix the issue with the standard ORM (e.g., `self.st_line_id.partner_name = False`) but it triggered a traceback. This occurs because `bank.rec.widget` is a virtual model defined with `_table_query = "0"`. When the ORM propagates the write operation, it attempts to query this virtual table `SELECT ... FROM (0)`. the fix now is a raw SQL update to set `partner_name` to NULL on the `account_bank_statement_line` to bypasses the ORM's dependency tracking for the virtual model. The cache is then explicitly invalidated to update UI. opw-5400705 Forward-Port-Of: odoo/enterprise#104596
1 change
Resolved issues and error corrections
This update resolves a user experience issue in the payroll module. When a previous payslip is required for after-departure payments, the system now displays a clear error message instead of a technical traceback. This ensures users receive helpful guidance and avoids confusion.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
11 changes
New functionality added to Odoo
This update introduces a new 'quick order' option within the Point of Sale (POS) system, allowing customers to place orders more quickly. The system now handles these instant orders and displays them appropriately, while also preventing changes to preparation times for quick orders.
Original PR description
Following this commit: ==== - Quick orders are now supported in pos system. - `is_instant_order` parameter is been handled in payload to fetch quick orders. - Preparation display would also be acknowledge if quick orders arrives in the preparation screen through `Quick order` tag. - For quick order , preparation time will non-editable task-5025473
Enhancements to existing features
This update simplifies the setup of Documents and Accounting actions, primarily by moving demo invoices to a more relevant location and streamlining how server actions are executed. It also includes visual refinements and resolves a technical issue related to action order, ensuring smoother operation for users.
Original PR description
This pr first moves 2 demo invoices that used to be installed in the Taxes folder when installing Documents with demo data. It is more relevant to add those files after a user has installed…
This pr first moves 2 demo invoices that used to be installed in the Taxes folder
when installing Documents with demo data. It is more relevant to add those
files after a user has installed accounting. The folder of the demo files
is now at the root of the 'Finance' folder instead of the less relevant 'Taxes' folder.
The second commit of this pr refactors the accounting server actions
(e.g., "Create Vendor Bill") to use a single `documents_account_record_create`
action instead of a `multi` action that combined a folder move with record creation.
Third commit removes a temporary workaround was required in `ir.actions.server` to enforce
a specific execution order for these multi-actions. This is fixed structurally by adding a default
order in the base module in community.
Additional improvements:
- When a journal is changed on an `account.move`, the tags from the previous
journal are now removed from the related document.
- `_get_folder_embedded_actions` now returns a `defaultdict`, simplifying
caller code by removing the need for manual `.get()` checks.
- Removed the "Create Vendor Receipt" action.
- Visual updates: Renamed actions for brevity (e.g., "Create Vendor Bill" ->
"Vendor Bill") and the cog menu button ("Add Custom Action" -> "Edit Actions").
Task-5075610This update enhances the Odoo Studio interface, specifically for m2o fields. It now allows users to apply decorations and set conditional rules based on the 'truthiness' of related fields, providing more flexible customization options for field attributes.
Original PR description
This commit exposes the `decoration-<modifier>=<field>` in studio for m2o fields. Once a decoration is selected, the Decoration Condition property is displayed and allow users to select a field from the model to conditionally add the attribute to the field. The condition depends on the "truthiness" of the field. task-5469063
This pull request delivers several updates to the CRM interface, including a streamlined lead generation dropdown and improvements to the lead-to-ticket conversion process within the helpdesk. It also incorporates extensions for city form data, enhancing data accuracy and usability.
Original PR description
A combination of many smaller improvements to CRM. See task description and commit messages for more info Community PR: https://github.com/odoo/odoo/pull/240202 Task-5262571
This update ensures consistent naming of customers across all Odoo rental documents. The pickup receipt PDF now uses 'Contact' instead of 'Salesperson,' aligning with the recent change in the sales order PDF. This improves document clarity and professionalism for our clients.
Original PR description
The term `Salesperson` can be used on end-customer documents. Replace it with `Contact` on the pickup receipt PDF for consistency with the sales order PDF change. task-5887854 See Also: Community PR:https://github.com/odoo/odoo/pull/246918
This update allows users to select multiple ledgers simultaneously for financial reports, simplifying report generation and providing more granular data control. A default 'Local GAAP' ledger is now included, and unnecessary date headers have been removed to streamline the report interface.
Original PR description
Instead of exclusion of journals, the journal groups (ledgers) are now an inclusion of journals. On the reports, we can now select multiple ledgers at the same time, and adding an implicit local ledger 'Local GaaP' which contains all the journals that are specific to the company, and not in any other ledger. This allows to select and deselect all these journals at once. This local Gaap is selected by default when entering the report. For the Horizontal Group based on Ledgers, addition of columns corresponding to the local gaap of each selected company. I also removed the date header when there is no comparison of dates in the report interface (not in the pdf), because the date can be seen on the filters. task-5404526
This update streamlines the Helpdesk search selector by collapsing priority, SLA status, and rating filters. This change optimizes screen space, making it easier for users to quickly find the tickets they need. It's a minor improvement to the user experience.
Original PR description
In this commit, we collapsed the priority, SLA status, and rating filters to free up some space in the search selector. task-5810884
This update strengthens the connection between documents and products within Odoo Enterprise. The changes streamline how documents are associated with products, making it easier to manage related information and improve product documentation workflows. This enhancement provides a more robust and intuitive system for businesses.
Resolved issues and error corrections
This update resolves an issue preventing users from duplicating payroll rule parameters, which caused a validation error. The change modifies the system to allow duplication while ensuring uniqueness through a technical update, enabling more flexible rule configuration. This improves the usability of the payroll module.
Original PR description
Description of the issue/feature this PR addresses: . For the rule parameter, when attempting to duplicate an existing record to edit it, a validation error is raised: “The operation cannot be completed: Two rule parameters cannot have the same code.” Current behavior before PR: . Prevent creation of duplicated rule parameter Desired behavior after PR is merged: . Override copy_data() method and append _copy to duplicated rule parameters to avoid uniqueness constraints. task-5913778
This update adds a bridge module to guarantee that the To-Do module is installed when using the mail alias feature within the HR system. Previously, uninstalling To-Do could cause issues because the feature remained within the HR module. This change ensures a smoother user experience and prevents unexpected problems.
Original PR description
This commit adds the `project_enterprise_hr_todo` bridge module that ensures that To-Do is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without To-Do installed. See odoo/upgrade#9469
This update improves the Odoo Studio interface by ensuring the 'Model Pages' tab is only visible when editing a model that's actively used and not a transient or abstract version. Previously, this tab could be enabled for irrelevant models, leading to potential confusion. This change aligns with stable releases and enhances the Studio's usability.
Original PR description
Before this commit, we could set publicly available webpages pointing to models that were irrelevant: - transient, - abstract, - sql_view: _auto = False, This was fixed at odoo/odoo#246115. This commit changes the display of the Model Pages tab in studio, as it was not possible to do so in stable. After this commit, when the current edited model is not a "concrete" one the model pages tab button is disabled. *: web_studio
7 changes
New functionality added to Odoo
This update ensures Odoo's Point of Sale system in Guatemala complies with local regulations. It automatically sets a default customer, prevents invoices for unidentified customers exceeding a set threshold, and applies company-specific tax phrases, ensuring successful submission to the Guatemalan tax authority (SAT).
Original PR description
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders…
Purpose: This module links the `point_of_sale` module with the `l10n_gt_edi` module. It is required in Guatemala to comply with Guatemalan Point of Sale legislation. Before this commit: - POS orders had no default customer. - Invoices generated for unidentified customers exceeding the legal threshold, leading to SAT rejections after submission. - GT Phrases configured on company were missing on the invoices generated through POS causing the electronic document to be rejected by SAT. After this commit: - Consumidor Final is set as the default customer on POS orders. - POS invoices cannot be generated for unidentified customers when the total exceeds the legal threshold (currently Q2500). - GT phrases configured on the company are now applied to POS invoices, ensuring valid electronic document submission to SAT. Technical Details: - Added a configurable legal threshold field on POS configuration. - Added validation to block invoicing when an unidentified customer exceeds the configured threshold. - Added a missing `super()` call in `l10n_mx_edi_pos` to ensure proper method chaining when multiple POS localizations are installed. related PR https://github.com/odoo/odoo/pull/242985 task-4393614
Resolved issues and error corrections
This update resolves an issue where adding components to work orders could trigger a technical error, preventing users from correctly managing work order components. The fix clarifies how work order moves are linked, ensuring accurate component display and preventing duplicate key errors.
Original PR description
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation…
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation to be performed in a workcenter - Confirm the MO and open the Shop Floor - Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display - Click on `Add component` and add any valid component via the catalog #### > Traceback: `OwlError: Got duplicate key in t-foreach` ### Cause of the issue: The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72 Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188 However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47 Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected. In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error. opw-5417887
This update corrects a technical issue in the Dutch reports module that was causing a program error. The fix ensures that the system correctly handles a boolean flag within a data structure, preventing a 'bool is not iterable' error. This ensures accurate report generation for Dutch customers.
Original PR description
After this [commit](https://github.com/odoo/enterprise/commit/402ec47),…
After this [commit](https://github.com/odoo/enterprise/commit/402ec47), [ec_sales_list_tag_ids](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_return.py#L21) is built by flattening the values of `ec_sales_list_tags_info` using `chain(*values())`.
The tag IDs are fetched from[ _get_tax_tags_for_nl_sales_report()](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_sales_report.py#L75), which returns a dictionary containing:
- a flag (`use_taxes_instead_of_tags = False`)
```.py
(Pdb) ec_sales_list_tags_info
{'goods': [67], 'services': [71], 'triangular': [69], 'use_taxes_instead_of_tags': False}
```
When flattening the dictionary values, `chain` expects all values to be iterable. While the boolean flag is not iterable,
which results in a `TypeError: 'bool' object is not iterable`.
```.py
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 493, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
In this fix, the boolean flag is removed before chaining since only tag ID lists are needed and the flag causes an error.The VoIP call history infinite scrolling feature has been fixed. Previously, it was limited to the last 13 calls in Chrome, but this update restores the full scrolling functionality. The issue was caused by a technical glitch related to how the browser detects scrolling, now resolved with a simple adjustment.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106658
This update corrects a previous issue where importing journal entries onto archived accounts would create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and prevents accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765 Forward-Port-Of: odoo/enterprise#106962
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of business hours. Adding a 'next business day' flag ensures rates are accurately determined, preventing errors and ensuring reliable shipping calculations. This improves the overall shipping process.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the `nextBusinessDay` flag for the rating request to avoid the issue. Error: `Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction')` opw-5393684
This update corrects a formatting issue where the total time on timesheet lists wasn't displayed correctly after a refresh. The fix ensures that the total time is formatted consistently, regardless of whether the user is viewing the timesheet in list or grid view. This improves the accuracy and usability of the timesheet reporting feature.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
21 changes
Enhancements to existing features
This update improves the generation of XML files for HR payroll in Croatia (l10n_hr_edi) by streamlining the process and adding more robust testing. Specifically, it addresses issues with tax calculations and API compatibility, ensuring accurate and compliant payroll reporting.
Original PR description
- Improving the ubl_hr method chain to include less overrides in favor of extensions - Adding proper handling of multiple tax total and tax category nodes for hrextac - Refining docstrings and comments for ubl_hr - Adding a test with multiple tax types - Adding a test for account_edi_ubl_cii_tax_extension integration - Adjusting MER methods to correspond to API changes: fiscalization queries are now only available for own documents task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces support for the new NFC-e QR Code v3, mandated by recent regulations in Brazil. Users can now select which QR code version (v2 or v3) to use for their companies, ensuring compliance with evolving industry standards and improving POS order validation.
Original PR description
Purpose: The NT2025.001 v1.02 released QR Code v3 for NFC-e. QR Code v3 should only include the following information: - Access Key - QR Code Version - Type of Enviroment Some states/UFs are starting to enforce the new QR Code v3 and it is mandated for the industry, Produtor Rural(Pessoa Fisica). Both QR Code v2 & v3 will need to be supported. Current Behavior: Only QR Code v2 is supported and is the default. Expected Behavior: The user will have the option to specify which QR Code version for each company in settings. When the user validates a POS order, the appropriate QR code version will be generated. The default version will be QR Code v2. task-5086655
Resolved issues and error corrections
This update resolves an issue preventing a key test case for website redirection functionality. The fix ensures the test runs correctly even without the standard demo data, which previously required a specific user group to be enabled. This change is limited to versions 18.2 and earlier.
Original PR description
Commit f86f6f6a3dc6bbeb8c68308aab2462b9c7bb935d (6th February 2026) added the test test_website_force_domain_redirect but it doesn't work without demo data because it was requiring "website.group_multi_website" group to be enabled. Fix: add the group for the test case in case it's not enabled. runbot-[238897](https://runbot.odoo.com/odoo/runbot.build.error/238897) opw-5441957 Note: this was noticed in saas-18.3 forward port so this is only necessary up to saas-18.2 version. Forward-Port-Of: odoo/odoo#248304
This update resolves a delay in reading data from Toledo scales. Previously, the system waited up to one second for a response. Now, it reads the scale data until a carriage return character is received, eliminating this delay and improving responsiveness. This ensures more accurate and timely data collection from these scales.
Original PR description
Before this commit, the `_get_raw_response` method would wait until the read timed out (1 second) before returning the response. After this commit, for the Toledo scale we instead read until we reach a `\r` character, which is at the end of the response. This eliminates the 1 second delay. Enterprise: https://github.com/odoo/enterprise/pull/107241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where comments within invoice XML files, specifically added to the TaxExclusiveAmount field, were causing the system to fail to recognize invoices. The fix ensures that the system correctly parses numerical values from XML, preventing empty invoices and improving invoice upload functionality.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
This update fixes a potential error that could occur when customers refunded orders, specifically when multiple orders were associated with the same customer. The change ensures that product information is loaded before refunds are processed, preventing errors and improving the reliability of the refund process. This enhances the overall customer experience and reduces the risk of order processing issues.
Original PR description
Before this commit, it was possible the cached toRefundLines included orderlines whose products were not loaded in the POS. This would cause an error when refunding another order for the same partner. This commit ensures that the product is loaded before refunding an orderline by using a new method in the POS store that loads the product if it is not already present in the database. opw-5384010 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244553
This update strengthens invoice security by preventing the use of untrusted accounts when processing inbound invoices. The team removed unnecessary calculations and logging logic, streamlining the process and relying on existing methods. This ensures invoices are handled securely and reduces potential risks.
Original PR description
fixed some tests and remove the computation logic from account_move_reversal wizard, to rely on existing compute method --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247954
This update fixes an issue where the working time to assign for tasks wasn't accurately calculated when switching between companies with different holiday settings. Now, the system correctly considers company-specific holidays when determining the task's working time, ensuring accurate time tracking across multiple companies.
Original PR description
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2…
__ Fix after revert bf9729e997b15777a981ac258b0088107804fbe6 __ Let's say we have 2 companies: company A and company B. We create a public time off of a few days starting before today and ending 2 days later in company A, then switch back to company B. In company B, we create a project and a task, and assign this task. The working time to assign will stay at 0. 1. Switch to company A and create a timeoff starting before today and ending later. 2. Switch back to company B. Create a project, a stage and a task. 3. Enable the debugger. 4. The field Working Time to Assign is invisible by default, so open studio, click on View, and check Show Invisible Elements. 5. Click on the tab Extra info and on the block Working time to assign. Uncheck Invisible. 6. Close studio and assign someone to the task. Make sure that you do this operation at a different time than the one recorded for the last stage change. The hours under Working Time to Assign should compute the difference between the last time the task got its stage changed and the time of assignation Nothing happens When computing the working time to assign, we also take into consideration leaves: if this happened during public holidays, we consider that it took no working time to get assigned. However, when a holiday is set in another company, the Working Time to Assign duration will be impacted, as the domain to retrieve the corresponding leaves is the following: https://github.com/odoo/odoo/blob/c7e965a61b7ce856c2daa8e2574cf4c60caf7a20/addons/resource/models/resource_calendar.py#L537-L546 The company isn't taken into account in the domain, applying the holiday for every company. __ opw-5222883
This update corrects a display issue within the Italian tax module (l10n_it_edi) where TC-XX codes weren't shown alongside pension fund type names. Previously, all other selection fields displayed codes first, but this field was an exception. This ensures accurate and consistent reporting for Italian businesses.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update resolves an issue where importing EDI invoices would fail when products were restricted to a different company. The fix ensures products are correctly identified during import, preventing 'Incompatible company' errors and improving the reliability of multi-company invoice processing. This improves data accuracy and reduces import failures.
Original PR description
In a multi-company environment, importing an EDI invoice could fail if a line contains a product restricted to another company. The error "Incompatible company on records" was raised because company consistency rules were applied.
Example steps to reproduce:
- Create two Italian companies, A and B
- In company A, create a product with default code or barcode "TEST"
- This can also occur using the barcode and the “Vendor Product code” from the Purchase supplier.
- Restrict this product to company A
- Create an EDI invoice in company A with this product for company B as customer
- Import the invoice in company B, which would fail
This fix adds a search domain to correctly find products during import
opw-5496912
Forward-Port-Of: odoo/odoo#248149This pull request fixes a problem where descriptions and product names were not consistently displayed on invoices during printing, particularly when importing factur-x e-invoices. The update ensures that complete invoice details, including descriptions and product names, are accurately printed in both standard and e-invoice formats. This improves the accuracy and clarity of invoices for customers and internal reporting.
Original PR description
**Issue 1** Steps to reproduce: - Create a new invoice - Add an invoice line, with just a description - Save - On the same line, add any product - Print Issue: Only the custom description will be visible on the line opw-5471809 --- **Issue 2** Steps to reproduce: - Import factur-x e-invoice - Print pdf Issue: Only product name will be printed, even if the invoice record include the complete description opw-5471809
This update fixes a potential issue where translation mapping could fail when the number of translated terms didn't perfectly match the base language. Now, the system gracefully falls back to the base language's values, preventing errors and ensuring more accurate translations. This improves the reliability of our translation process.
Original PR description
When the number of translated terms differs between the base language and its translation, fall back to the base value instead of attempting to map terms. This avoids potential errors and incorrect translation mappings. 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
This update addresses a minor bug in the HTML editor component that was causing errors when the focus element was missing. The fix uses a technique called 'optional chaining' to safely access the previous sibling, preventing the traceback and ensuring smoother editor functionality. This improves stability and reliability of the HTML editor.
Original PR description
Before this commit: in rectifySelection, the focusTarget can be null and causing an error when calling the previousSibling After this commit: now we do an optional chaining(?.) on previousSibling task-5481248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the shipping weight for deliveries wasn't accurately calculated when items were placed in packages. The fix ensures that the total weight of items within a package is correctly reflected in the delivery's shipping information, improving order accuracy and fulfillment.
Original PR description
Steps to reproduce: - Enable “Packaging” in Inventory settings. - Create a storable product “P1” with: - weight: 10 kg - Create a delivery picking: - Add one unit of P1 - Mark as “To Do” - Set…
Steps to reproduce:
- Enable “Packaging” in Inventory settings.
- Create a storable product “P1” with:
- weight: 10 kg
- Create a delivery picking:
- Add one unit of P1
- Mark as “To Do”
- Set quantity to 1 → the move becomes assigned and the picking weight is correctly computed to 10
- Click “Put in Pack” → a package is created with `shipping_weight = 0`, and the picking weight incorrectly computed to 0
Problem:
- `picking.shipping_weight` is computed as: `weight_bulk` + sum(`pack.shipping_weight or pack.weight`) https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L72-L79
- Once the product is placed in a package:
- `weight_bulk` becomes 0 (because Total weight of products which are not in a package). https://github.com/odoo/odoo/blob/17.0/addons/stock_delivery/models/stock_picking.py#L96
- `pack.shipping_weight` is 0 on creation.
- The fallback `pack.weight` is 0 because its compute depends on the `picking_id` in context. Without this context, the compute uses only quants https://github.com/odoo/odoo/blob/f7c033eff7b7bc83d6d18fc5e4df320f43ae5021/addons/delivery/models/stock_quant_package.py#L11-L13
opw-5357843
Forward-Port-Of: odoo/odoo#238917This update fixes an issue where the tax report (mod 390) was displaying duplicate amounts for EU import transactions. The problem stemmed from an incorrect tax tag definition within the Spanish localization module. This ensures accurate reporting of VAT on imported goods, aligning with Spanish tax regulations.
Original PR description
How to reproduce: - Install the l10n_es module - Switch to a spanish company - Confirm a Vendor Bill with a Product with the tax 0% EU G - Go to the Tax Report and select mod390 The problem: In the section "Adquisiciones intracomunitarias de bienes", the total amount is shown two time, once for grid 716 and once for grid 26 Why: In the declaration of the tax template for 0% EU G, there is two tags for the mod 390, the one for grid 26 being wrong Before: <img width="818" height="447" alt="image" src="https://github.com/user-attachments/assets/0565802d-5d98-4e0f-9e08-50776f0a5aec" /> After: <img width="834" height="443" alt="image" src="https://github.com/user-attachments/assets/89696c83-7022-439d-adaa-d456c2dbadf8" /> opw-5867849 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247590
A recent test was causing build errors due to inconsistent leave requests, particularly when coinciding with legal holidays. This commit corrects the test to ensure leave is always requested for the intended date, resolving the build issues and improving test stability. This change ensures accurate leave processing during testing.
Original PR description
The test 'test_holiday_responsible_refuse_leave' is creating build errors in the runbot, it requests a leave for the current day, which can fall on a legal day off, and will then result in an error. This commit ensures the leave is consistently requested for a correct date. https://runbot.odoo.com/odoo/runbot.build.error/237917
This update corrects a technical issue that was preventing Odoo e-invoices from passing PDF/A-3 validation. The previous code incorrectly stored file sizes as text strings instead of numbers, leading to validation errors. This fix ensures our e-invoices meet industry standards for archiving, improving compliance and reducing potential issues with document processing.
Original PR description
The `/Size` parameter in embedded file `/Params` was being set using `NameObject` instead of `NumberObject`, resulting in the size value being stored as a PDF Name Object (e.g., `/19410`) rather than a numeric integer (`19410`).
This causes PDF/A-3 validators to report zero-size or invalid attachments, breaking compliance with ISO 19005-3 (PDF/A-3A).
Steps to reproduce:
- Generate an e-invoice PDF with XML attachments (e.g., Factur-X)
- Validate the PDF with veraPDF or Adobe Acrobat Preflight
- Embedded file size is reported as zero or invalid
Fix:
```diff
- NameObject('/Size'): NameObject(f"/{len(attachment['content'])}"),
+ NameObject('/Size'): NumberObject(len(attachment['content'])),
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-prThis update fixes an issue where invoices created in foreign currencies weren't accurately displaying the converted amount in the company's local currency (Saudi Riyal) on the invoice report. The change ensures that amounts are correctly rate-adjusted, providing accurate financial reporting for Saudi Arabian businesses using Odoo. This resolves a discrepancy in the reporting of invoice totals.
Original PR description
After 267a876451da8b39ab8c5885e7198ebfeb841573 invoice report will not show the correct amount in company currency Steps to reproduce: - With SA Company setup - Create invoice in foreign currency - Print Issue: Amount in company currency have not been rate adjusted. This occurs because amount_untaxed and amount_total are expressed in foreign currency. 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#245840
This update resolves an issue where users could trigger errors when entering non-numeric values in the serial/lot number field. By changing the field's input type to 'number' and adding a keypress handler, the system now correctly validates input, preventing errors and ensuring reliable serial number generation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed. Forward-Port-Of: odoo/odoo#248221
This update corrects a bug where nodes containing directives (like 'groups') were incorrectly identified as translatable. This prevented proper translation of certain elements within the Odoo interface. The fix ensures that only standard elements are considered for translation, improving the accuracy of translated content.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag. Forward-Port-Of: odoo/odoo#246354
This update resolves a discrepancy in the scale certificate checksum, aligning it with a recent fix implemented in the core Odoo platform. This ensures accurate verification of the certificate and maintains compliance standards. The change was driven by a community-developed improvement.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413.
4 changes
Resolved issues and error corrections
This update resolves an issue where attendance managers couldn't correctly edit the attendance records of their subordinates. The fix ensures both managers and officers can now modify attendance data, improving workflow efficiency. The changes also included enhanced testing for greater reliability.
Original PR description
The commit https://github.com/odoo/odoo/commit/d115cca1296c0bd20a2875bdaadf2a9136c33dda introduced the opportunity for attendance managers to edit their subordinates attendances, but the condition was lacking parenthesis, leading to an unexpected behaviour. This commit changes the condition so that it is possible both for a manager and an officer to do the edition. It also rewrite the tests in order to be more thorough. No related task
This update resolves an issue where comments within XML invoices (specifically around TaxExclusiveAmount) were causing the system to fail to recognize and process invoices. The fix ensures that comments are removed during XML parsing, allowing invoices to be correctly uploaded and processed. This prevents empty invoices from being created.
Original PR description
Issue: Comments in node with data as text may cause issue while reading data Step to reproduce: - In European company create an invoice to a company in the same country - Send it with peppol - Download the XML of the invoice - Add a comment right before the value in TaxExclusiveAmount like this <cbc:TaxExclusiveAmount><!-- -->0.00</cbc:TaxExclusiveAmount> - Go to accounting Dashboard - Click on "Upload" in the vendor dashboard - Select the previously modified XML Current behavior: - an empty invoice is created as the invoice builder failed Expected behavior: - Invoice should be recognized Cause: lxml treat data like this: <parentNode>parent_text<childNode>child_text</childNode>child_tail</parentNode>parent_tail So `tax_exclusive_amount_node.text` return '' instead of `0.00` opw-5462664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247549
This update corrects a bug where Odoo incorrectly reported stock availability in the past, particularly when considering stock locations within a hierarchy. The fix ensures that available quantities are accurately calculated, reflecting actual stock levels as of a specified date, even when locations are nested. This improves the reliability of stock reports and inventory management.
Original PR description
Problem, Odoo check the stock.move to decrease the quantity if we want available product quantity in a past. If i valid a stock move for new product with location_dest_id = A and stock.move.line with location_dest_id = B (B child of A) and i check the quantity in a past in B location, Odoo return the quant quantity in B location without decrease the last move line. Before fix: product.with_context(location=B).qty_available = 1 product.with_context(to_date="2025-09-01", location=B).qty_available = 1 After fix: product.with_context(location=B).qty_available = 1 product.with_context(to_date="2025-09-01", location=B).qty_available = 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding the 'studio_assets' bundle to the pregeneration list, tests now run more efficiently and reliably. This improves overall development speed and stability.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.