Daily updates from Odoo
Friday, February 13, 2026
54 changes · saas-19.1
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
This update resolves an issue preventing users from modifying POS Daily Sales Reports (PDIS) when a POS session was active. Now, users can create and edit PDIS regardless of whether there are active orders, improving workflow flexibility. This change ensures consistent reporting capabilities.
Original PR description
Steps to reproduce : 1. Open a POS session 2. Create a pdis with all PoS 3. An error is raised So now, when we creating a new pdis or when there is no ongoing orders in this pdis, we allow to modify it. But if there is ongoing orders, user cannot. task : 5881587 Forward-Port-Of: odoo/enterprise#105736
This update resolves a formatting problem where the total time on timesheets in the list view wasn't displaying correctly after a page refresh. The fix ensures that the total time is formatted consistently, regardless of whether the user is viewing the data in a grid or list format. 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 display issue in the rental schedule's Gantt view where a product grouping filter reappeared after being removed. The fix removes a conflicting default setting, ensuring the Gantt view behaves as expected and users can consistently control product groupings. This improves the user experience when managing rental schedules.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Install the Rental and Inventory apps. 2. Go to the rental schedule. 3. Observe the gantt view is grouped by product by default. 4. Remove the product groupby…
Versions -------- - 19.0+ Steps ----- 1. Install the Rental and Inventory apps. 2. Go to the rental schedule. 3. Observe the gantt view is grouped by product by default. 4. Remove the product groupby filter. Issue ----- The product groupby filter reappears. Cause ----- The base gantt view defines `default_group` as product. Additionally, the `sale_stock_renting` module overrides the `sale_renting.action_rental_order_schedule` action to add two default groupby filters: `search_default_groupby_product` and `search_default_groupby_reserved_lot`. This creates conflicting defaults: one from the gantt view directly (groupby product) and another from the context (groupby product and reserved lot). Since lots are disabled by default, the lot groupby filter is ignored. When removing the product filter, the framework falls back to `default_group` and reactivates the product groupby filter. Solution -------- Remove the `default_group` parameter from the gantt view. Ensure all actions using the gantt view define their own defaults via context. opw-5887837 Forward-Port-Of: odoo/enterprise#107008
This update corrects a bug where holiday attest documents incorrectly rounded leave allocations (e.g., 19.5 days became 19 days). The fix changes internal data types to handle decimal values accurately, ensuring correct holiday allocation figures are displayed. This prevents discrepancies in payroll reports.
Original PR description
Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation). The same problem happens if the number of leaves taken is not an integer…
Bug : allocate a number of holidays that is not an integer (ex : 20.5), then check the holiday attest (shows 20 allocation).
The same problem happens if the number of leaves taken is not an integer
Steps : - in the belgian company, create a new employee with a valid contract give an employee 19.5 days of Time Off type leaves.
- on the form view of the employee , click on the action button -> Departure: Notice period and payslip -> and fire the employee.
- now click on action button -> Departure: Holiday Attests, you'll see that the employee has 19 allocated instead of 19.5
Reason : The number of leave_allocation_count and leave_count are defined as integers in HrPayslipEmployeeDepatureHolidayAttestsTimeOffLine, when they are populated, they end up casting the assigned value to an int.
Fix : Create two new float fields leave_count_float and leave_allocation_count_float to replace their corresponding integer fields.
task - https://github.com/odoo/enterprise/commit/5461268c9411d36feac90cd45dcff42aab59599b
Forward-Port-Of: odoo/enterprise#103258This update corrects a discrepancy in the Belgian payroll calculations by incorporating the latest car ATN (acquisition-linked tax number) data up to 2026. This ensures accurate tax calculations for employees using company cars in Belgium, aligning with current tax regulations and improving payroll accuracy.
Original PR description
TaskID: 5932573 Forward-Port-Of: odoo/enterprise#107237
This update resolves an issue where tests were unintentionally executed twice, impacting system performance. The fix ensures tests run only once, streamlining the process and improving overall system stability. This change is a routine maintenance update.
Original PR description
Forward-Port-Of: odoo/enterprise#106911
This update addresses a technical issue preventing accurate report date filtering when using Faketime builds. The fix skips a problematic test case specific to Faketime, ensuring report functionality works correctly for standard builds. Future versions (19.2+) will have a more robust solution.
Original PR description
Faketime doesn't integrate well with our current version of the report date filter. JS date is not frozen, so the filter misbehaves. It's working OK for all other builds. Future versions (19.2+) will probably have another version of the filter which should have a different implementation, solving the problem in another way. Reworked and backported from: odoo/enterprise#101689 Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#107186 Forward-Port-Of: odoo/enterprise#106172
This update fixes a display issue where tax amounts were incorrectly shown as negative in the tax totals widget for credit notes in Brazil (BR). The fix ensures that tax calculations are accurate, presenting the correct tax amount for financial reporting and reconciliation. This resolves a prior bug impacting financial accuracy.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#107177 Forward-Port-Of: odoo/enterprise#106579
This update resolves a minor issue related to the scale certification process for European IoT solutions. It synchronizes a key checksum value following a recent fix implemented in the main Odoo repository. This ensures consistent and accurate certification calculations.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248416. Forward-Port-Of: odoo/enterprise#107246
This update resolves an issue where adding components to work orders could trigger a technical error, preventing users from correctly managing their shop floor operations. The fix clarifies how work order moves are linked, ensuring accurate display and preventing duplicate data entries.
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 Forward-Port-Of: odoo/enterprise#106200
This update corrects a calculation error in how mobility budgets are determined for employees in Belgium. The change implements an iterative method to ensure budgets align with legal limits and are appropriately scaled based on employee wages, leading to more accurate payroll processing.
Original PR description
We implement in this PR the iterative computation method of mobility budget. Given an employer cost, we find the wage and mobility budget such that mobility budget amount respect legal constraints of minimum and maximum and rate with respect to wage
This update fixes an issue where invoices sent to DIAN were incorrectly flagged with a warning if the invoice date was within a specific range. The change aligns the invoice date validation with Colombian regulations, allowing for a 6-day window around the current date for invoice creation, ensuring compliance with DIAN requirements.
Original PR description
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN`, if the invoice date is 6 days before today, even though this date should be considered valid. **Steps to…
Currently, an `incorrect warning` message is shown when sending an invoice to `DIAN`, 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], 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. **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/62f59f87a513a86a61f871ca743e7f7b04926a82/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1086-L1093 [3]: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Documento-Soporte-No-Obligados.pdf opw-5482555 Forward-Port-Of: odoo/enterprise#107372 Forward-Port-Of: odoo/enterprise#105763
This update resolves a bug that was preventing users from correctly applying amounts to bank reconciliation lines. The fix ensures that amounts are calculated using the correct currency (amount currency) instead of the balance, improving the accuracy of reconciliation processes. This change impacts the way users can adjust amounts when reconciling transactions.
Original PR description
In this commit: We broke the way the apply amount work, this commit will solve that. For the apply full amount, we modified the field fetch by fetchReconciledLines and also the substraction of the amount currency to use the amount currency and not the balance For the partial, keep it like before we actually take the value of the suspense so it's ok. opw-5925046 Forward-Port-Of: odoo/enterprise#107377
This update ensures the OCR functionality correctly processes receipts, resolving an issue where the 'Digitize document' button wouldn't work when a receipt was manually set. Previously, incorrect tax calculations were occurring on sale receipts. This fix improves the accuracy of receipt processing and ensures OCR works as expected.
Original PR description
Since the OCR is available on receipts (commit a7e9575), the calls to `is_purchase_document`/`is_sale_document`/`is_invoice` need to have the `include_receipts` parameter set to `True` to return an accurate value. This was omitted in the original commit and later fixed in commit 0dc9352, but only for calls to `is_purchase_document`. This commit fixes it for calls to `is_sale_document` and `is_invoice`. The missing parameters caused the following bugs: - OCR not available on receipts, i.e. if the user manually sets the invoice as a receipt, the "Digitize document" button was there, but it wouldn't work. - Purchase taxes would be used instead of sale taxes for sale receipts. These use cases aren't very common, probably why there was no ticket to report it. task-none Forward-Port-Of: odoo/enterprise#107272
This update resolves an issue where customer display URLs weren't consistently being sent to IoT devices when records were updated. The change ensures the correct URL is transmitted, improving the functionality of the IoT integration. This fix was triggered by a bug in the update process.
Original PR description
This PR fixes the customer display url not being sent to the iot box when updating the corresponding record in iot device form view. By replacing onWillSaveRecord by onRecordSaved we ensure that our method is always called ticket-5782927 Forward-Port-Of: odoo/enterprise#106621 Forward-Port-Of: odoo/enterprise#106331
This update resolves an issue where approval feedback wasn't being recorded within Odoo. The recent code changes have corrected this by ensuring feedback is now posted as a message, allowing for accurate tracking of approvals and feedback within the web studio interface. This ensures a smoother workflow for users providing and receiving feedback on approvals.
Original PR description
Approving an approval via an activity with feedback did not work properly as the feedback was never posted. This was due to the consecutive refactoring that broke the feature. After this commit, the feedback is posted as a message opw-5782803 Forward-Port-Of: odoo/enterprise#106185
This update resolves a misleading warning that appeared in the Belgian tax report when negative values were generated from carryover lines. The fix ensures that carryover lines correctly produce positive values, eliminating the unnecessary and confusing warning. This improves the accuracy and reliability of the report.
Original PR description
The Belgian tax report was displaying a warning when a negative amount originated from all the lines even from carryover ones. This warning was misleading, as carryover lines are not supposed to generate a declared negative value. task-5411005 Forward-Port-Of: odoo/enterprise#103046