Friday, February 13, 2026
35 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 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 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
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 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 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 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 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 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 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 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
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 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