Daily updates from Odoo
Friday, February 13, 2026
89 changes
35 changes
Resolved issues and error corrections
This update resolves an issue where the "Add to Cart" button in the product configurator would wrap awkwardly on smaller screens. The changes adjust the button's styling to ensure the text remains readable across different device sizes, improving the user experience and preventing a potential frustration for customers.
Original PR description
This commit fixes some text wrapping issues for the buttons inside the product configurator: - Change "Add to Cart" text visibility from d-md-inline to d-lg-inline for better mobile layout and prevent text wrapping - Add text-nowrap class to configurator's footer primary button to prevent text wrapping task-5896776 | Before | After | |--------|--------| | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/fa9106df-c8ee-4ade-a8ce-466549b8e816" /> | <img width="1029" height="781" alt="image" src="https://github.com/user-attachments/assets/70de2a6a-b6d8-43da-bbdb-97e1b921078b" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248016
This update 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
5 changes
Resolved issues and error corrections
The infinite scrolling feature for VoIP call history was temporarily broken in Chrome. This fix resolves the issue by addressing a technical problem with how the software detects the end of the scrolling list, ensuring all calls are now displayed correctly. This improves the user experience for managing VoIP calls.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106658
This update corrects a previous issue where importing journal items onto archived accounts would inadvertently create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and prevents accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765 Forward-Port-Of: odoo/enterprise#106962
This update resolves a visual bug where the total time on the timesheet list view wasn't correctly formatted after a refresh. The fix ensures that the total time is displayed as a time value, matching the format of individual timesheet entries. This improves the user experience and accuracy of timesheet reporting.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
This update resolves an issue where tests were unintentionally run twice within the delivery ups integration module. This improvement ensures more efficient system performance and reduces potential strain on resources. The fix was implemented to maintain smooth and reliable operation of the delivery process.
Original PR description
Forward-Port-Of: odoo/enterprise#106911
This update resolves a misleading warning appearing in the Belgian tax report. The issue stemmed from a false negative value being generated by carryover lines, which are not intended to produce negative figures. This change ensures the report displays accurate information and avoids unnecessary alerts.
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
8 changes
Resolved issues and error corrections
This update resolves a technical issue that caused the Odoo application to crash when using the Ukrainian language. The fix ensures that the application gracefully handles missing data patterns from CLDR, preventing errors and improving stability for users in this region. This change focuses on internal application performance.
Original PR description
**Steps to Reproduce:** 1. Install `stock_fleet` module (with demo data). 2. Set the **Ukrainian** language for the user. 3. Open Fleet > Vehicle > Click Category Error: `KeyError: '2'` **Cause:** Babel's CLDR list patterns for some locales (e.g., Ukrainian 'unit-short') do not include the two-item pattern key, so when babel's `format_list` attempts to access patterns, it will raise an error. **Fix:** This commit wraps the call in a try/except that handles KeyError and retries formatting with the 'standard' style to avoid the crash. Forward-Port-Of: odoo/odoo#248228
This update corrects a visual issue in the Italian tax module (l10n_it_edi) where TC-XX codes weren't displayed alongside pension fund type names. The fix ensures consistency with other selection fields, improving clarity and usability for Italian businesses using the Odoo accounting system.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update corrects a rare display problem in Firefox where the HTML editor would create duplicate buttons and links with unexpected text placement. The fix resets the browser's internal state related to links, ensuring proper button and link rendering across different browsers. This improves the overall user experience within the HTML editor.
Original PR description
In some situations Firefox behaves strangely when adding a character add the end of a button, by duplicating the button element without children and inserting the text between both buttons. It seems Firefox maintains an internal selection state that is corrupted after some operations. This commit resets the collapsed selection inside links in order to reset this internal state in Firefox. Steps to reproduce: - Insert a link - Put some text after the link - Delete the first character from the text - Keep deleting until the last character from the button is deleted - Type a character => The button was duplicated and the text was inserted between both buttons. - Note that if you undo/redo, then typing a character did work fine task-5033890 Forward-Port-Of: odoo/odoo#241895
This update fixes a bug where empty loyalty cards were created when not all loyalty programs applied points to an order. Now, loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data cleanliness. This ensures accurate loyalty program tracking.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#247491 Forward-Port-Of: odoo/odoo#244254
This update corrects a previous issue where importing journal entries onto archived accounts would inadvertently create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and avoids potential accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765
This update fixes an issue where the total time on timesheets displayed in the list view was incorrectly formatted as a regular number instead of a time. The fix ensures that the total is always displayed in the correct time format, regardless of page refreshes. This improves the accuracy and usability of timesheet reporting.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
This update corrects a UI issue where the partner name incorrectly remained displayed on bank statement lines after removing a partner from the bank reconciliation widget. The fix uses a direct database update to clear the partner name field, ensuring the UI accurately reflects the current partner information. This improves the user experience and data accuracy.
Original PR description
When a user removes the partner from the liquidity line in the bank reconciliation widget, the 'partner_name' field on the statement line is not cleared. This results in the UI displaying the old name even though the partner is removed. in the first time i wanted to fix the issue with the standard ORM (e.g., `self.st_line_id.partner_name = False`) but it triggered a traceback. This occurs because `bank.rec.widget` is a virtual model defined with `_table_query = "0"`. When the ORM propagates the write operation, it attempts to query this virtual table `SELECT ... FROM (0)`. the fix now is a raw SQL update to set `partner_name` to NULL on the `account_bank_statement_line` to bypasses the ORM's dependency tracking for the virtual model. The cache is then explicitly invalidated to update UI. opw-5400705 Forward-Port-Of: odoo/enterprise#104596
This update fixes a discrepancy in the Belgian payroll module (l10n_be_hr_payroll) by incorporating the latest car ATN (acquisition-termination) data up to 2026. This ensures accurate tax calculations and reporting for Belgian businesses using the Odoo Enterprise system. The change corrects a previous data limitation, maintaining compliance with Belgian tax regulations.
Original PR description
TaskID: 5932573 Forward-Port-Of: odoo/enterprise#107237
2 changes
Resolved issues and error corrections
This update corrects a discrepancy in the calculation of car tax (ATN) for employees in the Belgian payroll module. The update incorporates tax rates and regulations up to 2026, ensuring accurate tax deductions for employees with company vehicles. This ensures compliance with Belgian tax laws and accurate payroll reporting.
Original PR description
TaskID: 5932573 Forward-Port-Of: odoo/enterprise#107237
This update corrects a checksum issue related to the EU IoT scale certification process. It's a necessary step to ensure accurate reporting and compliance following a recent fix in the main Odoo project. This change maintains the integrity of financial data for European customers.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413. Forward-Port-Of: odoo/enterprise#107241
1 change
Resolved issues and error corrections
This update resolves a user experience issue in the payroll module. When a previous payslip is required for after-departure payments, the system now displays a clear error message instead of a technical traceback. This ensures users receive helpful guidance and avoids confusion.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
13 changes
Resolved issues and error corrections
This update resolves an issue preventing users from duplicating payroll rule parameters, which caused a validation error. The change modifies the system to allow duplication while ensuring uniqueness through a technical update, enabling more flexible rule configuration. This improves the usability of the payroll module.
Original PR description
Description of the issue/feature this PR addresses: . For the rule parameter, when attempting to duplicate an existing record to edit it, a validation error is raised: “The operation cannot be completed: Two rule parameters cannot have the same code.” Current behavior before PR: . Prevent creation of duplicated rule parameter Desired behavior after PR is merged: . Override copy_data() method and append _copy to duplicated rule parameters to avoid uniqueness constraints. task-5913778
This update adds a bridge module to guarantee that the To-Do module is installed when using the mail alias feature within the HR system. Previously, uninstalling To-Do could cause issues because the feature remained within the HR module. This change ensures a smoother user experience and prevents unexpected problems.
Original PR description
This commit adds the `project_enterprise_hr_todo` bridge module that ensures that To-Do is correctly installed in order to use the todo mail alias feature. Before, this requirement was not enforced so anyone uninstalling To-Do could experience some issue, as the feature would still be part the `project_enterprise_hr` module, even without To-Do installed. See odoo/upgrade#9469
This update improves the Odoo Studio interface by ensuring the 'Model Pages' tab is only visible when editing a model that's actively used and not a transient or abstract version. Previously, this tab could be enabled for irrelevant models, leading to potential confusion. This change aligns with stable releases and enhances the Studio's usability.
Original PR description
Before this commit, we could set publicly available webpages pointing to models that were irrelevant: - transient, - abstract, - sql_view: _auto = False, This was fixed at odoo/odoo#246115. This commit changes the display of the Model Pages tab in studio, as it was not possible to do so in stable. After this commit, when the current edited model is not a "concrete" one the model pages tab button is disabled. *: web_studio
This update adjusts the tests for the spreadsheet sale management feature to align with a recent update to the Odoo spreadsheet library. This ensures the tests accurately reflect the current functionality and helps maintain the stability of the sale process. The change is a technical update to the testing framework.
This update addresses a technical issue related to how Odoo fetches email data, improving the performance and stability of email-related operations within the Enterprise edition. The change removes a workaround that was impacting query counts, ensuring more efficient email processing. This ultimately leads to a smoother user experience for email functionality.
Original PR description
Update query count. https://github.com/odoo/odoo/pull/221906
This update fixes an issue where icons on delivery buttons were displaying incorrectly due to a technical error in how they were defined. The change ensures consistent and accurate icon rendering across key delivery modules like Easypost, Shiprocket, and Starshipit, improving the user experience. This resolves a visual inconsistency and ensures proper functionality.
Original PR description
*: easypost, shiprocket, starshipit The proper syntax for buttons with icons is to use the icon="" keyword instead of manually defining the font within a class attribute. When it is implemented via…
*: easypost, shiprocket, starshipit The proper syntax for buttons with icons is to use the icon="" keyword instead of manually defining the font within a class attribute. When it is implemented via the class attribute any string attribute on the button appears in some random sarif font instead of the standard odoo text font. Before / After Easypost <img width="256" height="127" alt="image" src="https://github.com/user-attachments/assets/56cae398-ea49-4961-b599-eab493efa02f" /> <img width="301" height="130" alt="image" src="https://github.com/user-attachments/assets/11c7bf47-41c3-4c18-b218-7d61831ae2cb" /> Shiprocket <img width="213" height="101" alt="image" src="https://github.com/user-attachments/assets/caaef053-7209-41e8-a0aa-46e3ba018cd9" /> <img width="217" height="116" alt="image" src="https://github.com/user-attachments/assets/940c753f-06a8-4ce0-95a9-b8c2024aa9eb" /> Starshipit <img width="365" height="141" alt="image" src="https://github.com/user-attachments/assets/861671b8-77d0-44c2-bc27-bb68d638788a" /> <img width="361" height="144" alt="image" src="https://github.com/user-attachments/assets/382deef4-8251-47fc-8ae4-66786da01506" />
This update simplifies the view editor by resetting options to null when a field's widget is changed. Previously, the system retained compatible options, which became unreliable with increasingly specialized widgets. This change improves the stability and predictability of the view editor experience.
Original PR description
/!\ Behaviour change /!\ Historically, when changing a widget on a field via studio, options were kept. This allowed for the user to circle back and keep mostly compatible options between widgets that handle the same field types. That assumption is becoming more and more fragile as field widgets become more and more specialized. After this commit, when changing the widget that handles a field, we reset the options to `null` task-4194461
This update enhances the visual consistency of the Point of Sale (POS) navbar across different Odoo modules (pos_appointment, pos_enterprise, pos_urban_piper). Specifically, it addresses inconsistent button styling, improves appearance in dark mode, and updates the delivery badge and button for a more polished user experience.
Original PR description
*: pos_appointment, pos_urban_piper Before this commit, the POS navbar had inconsistent button styling. Alongside the community commit improving the navbar and buttons hierarchy, this one focus on improving btn-light active state and border color for dark mode, and improving the delivery badge & button. requires: https://github.com/odoo/odoo/pull/248273 task-5905481
This pull request fixes a minor typo – 'Theorical' – to 'Theoretical' within the MRP Workorder module. This ensures consistent terminology across the codebase, improving clarity and preventing future errors. The change is a standard quality assurance update.
Original PR description
Rename the related occurrences in the codebase to maintain consistent terminology and help prevent similar issues in the future. task-5137717
This update automatically activates a cron job that fetches vendor bills based on IRN (Invoice Reference Number) only when the user enables automatic GST e-invoice retrieval. This change ensures that the system doesn't unnecessarily consume resources and improves performance for users who don't require this specific functionality. It's a targeted fix to optimize the process.
Original PR description
The cron to fetch the vendor bill based on IRN is disabled by default and only activates if the user changes the `l10n_in_gstr_activate_einvoice_fetch` to `automatic`. see https://github.com/odoo/upgrade/pull/9423 task-5885482
This update resolves an issue related to how product locations are managed within Odoo. The changes optimize the internal processes for retrieving location data, ensuring more accurate and efficient product tracking. This improves the reliability of inventory and sales operations.
This update adjusts the tests for the spreadsheet sale management feature to align with recent changes to the Odoo spreadsheet library. This ensures the tests accurately reflect the current functionality and helps maintain the stability of the sale process. The change is a minor fix to improve test reliability.
This update reverts a recent change to how call durations are displayed in the Odoo Enterprise system. Previously, call durations were shown in a standard numeric format (e.g., 1:23:43). This fix ensures that call durations are displayed consistently, providing users with the familiar and expected format.
Original PR description
This commit is a followup of odoo/enterprise#102439 where a new formatting of duration has been introduced. This formatting doesn't fit for the voip usecase, so this commit forces the "numeric" display, which was the one used previously. In other words, call durations will be displayed like "1:23:43" as before.
11 changes
Resolved issues and error corrections
This update resolves an issue where adding components to work orders could trigger a technical error, preventing users from correctly managing work order components. The fix clarifies how work order moves are linked, ensuring accurate component display and preventing duplicate key errors.
Original PR description
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation…
### Steps to reproduce: - Enable debug mode (to trigger a traceback rather than a silent error) - In the settings, enable `Work Orders` - Create an MO for a product without a BoM - Add an operation to be performed in a workcenter - Confirm the MO and open the Shop Floor - Enable the workcenter of your operation, switch to it, and click on the three dots at the bottom right of the operation display - Click on `Add component` and add any valid component via the catalog #### > Traceback: `OwlError: Got duplicate key in t-foreach` ### Cause of the issue: The rendering error is raised by the `MrpDisplayRecord` template: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.xml#L69-L72 Two moves with the same `id` are provided to the template. Which is unexpected since the `moves` getter should not return the same move twice: https://github.com/odoo/enterprise/blob/51ce336f8dac9ba0a8ca719201640b2829044164/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L174-L188 However, neither of the two move pools is well defined. The issue stems from the confusing `operation_id` field, which should rather be `workorder_id`. Currently, the moves associated with the MO are those not linked to an `operation_id` (i.e., not linked to an `mrp.routing.workcenter` from the BoM), whereas they should instead be those linked to a `workorder_id`, representing an operation of the MO: https://github.com/odoo/odoo/blob/0d7e3d4c0ea976e37871ca44a10a442cce7caa85/addons/mrp/models/stock_move.py#L43-L47 Similarly, moves linked to workorders are only those matching the same `operation_id` as the workorder. This can only happen when the workorder is generated from the BoM and therefore has a set `operation_id`, or when both are `False`. In the latter case, all moves unlinked to any `operation_id` are displayed on all operations not generated by the BoM, which is again completely unexpected. In the present case, our operation has not been generated from the bom and hence will fall in both move pulls for the unexpected reason leading to the duplicate key-error. opw-5417887
This update corrects a technical issue in the Dutch reports module that was causing a program error. The fix ensures that the system correctly handles a boolean flag within a data structure, preventing a 'bool is not iterable' error. This ensures accurate report generation for Dutch customers.
Original PR description
After this [commit](https://github.com/odoo/enterprise/commit/402ec47),…
After this [commit](https://github.com/odoo/enterprise/commit/402ec47), [ec_sales_list_tag_ids](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_return.py#L21) is built by flattening the values of `ec_sales_list_tags_info` using `chain(*values())`.
The tag IDs are fetched from[ _get_tax_tags_for_nl_sales_report()](https://github.com/odoo/enterprise/blob/c6b8727b9c926a4f817249b94cfc24dcbd66147f/l10n_nl_reports/models/account_sales_report.py#L75), which returns a dictionary containing:
- a flag (`use_taxes_instead_of_tags = False`)
```.py
(Pdb) ec_sales_list_tags_info
{'goods': [67], 'services': [71], 'triangular': [69], 'use_taxes_instead_of_tags': False}
```
When flattening the dictionary values, `chain` expects all values to be iterable. While the boolean flag is not iterable,
which results in a `TypeError: 'bool' object is not iterable`.
```.py
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
load_modules(
File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 493, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 220, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/19.0/odoo/modules/migration.py", line 257, in exec_script
mod.migrate(cr, installed_version)
File "/tmp/tmpzg7oi478/migrations/account_reports/saas~18.3.1.0/end-account-returns.py", line 341, in migrate
generate_or_refresh_all_returns(company)
File "/home/odoo/src/enterprise/19.0/account_reports/models/account_return.py", line 232, in _generate_or_refresh_all_returns
self._generate_all_returns(fiscal_country.code, company, domestic_tax_unit)
File "/home/odoo/src/enterprise/19.0/l10n_nl_reports/models/account_return.py", line 22, in _generate_all_returns
ec_sales_list_tag_ids = list(chain(*ec_sales_list_tags_info.values()))
TypeError: 'bool' object is not iterable
```
In this fix, the boolean flag is removed before chaining since only tag ID lists are needed and the flag causes an error.The VoIP call history infinite scrolling feature has been fixed. Previously, it was limited to the last 13 calls in Chrome, but this update restores the full scrolling functionality. The issue was caused by a technical glitch related to how the browser detects scrolling, now resolved with a simple adjustment.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#106658
This update corrects a previous issue where importing journal entries onto archived accounts would create duplicate accounts. Now, the import process correctly links to the existing archived account, and an error is triggered during confirmation to maintain data accuracy. This ensures data integrity and prevents accounting discrepancies.
Original PR description
Allow importing journal items on archived accounts without silently creating duplicate accounts. Odoo previously bypassed the uniqueness constraint on account codes when the target account was archived. Now, the import process links to the existing archived account instead of creating a new one. An error will still be raised during the confirmation of the journal entries to ensure data integrity task-5417765 Forward-Port-Of: odoo/enterprise#106962
This update resolves an issue where DHL shipping rate calculations failed when requested for dates outside of business hours. Adding a 'next business day' flag ensures rates are accurately determined, preventing errors and ensuring reliable shipping calculations. This improves the overall shipping process.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the `nextBusinessDay` flag for the rating request to avoid the issue. Error: `Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction')` opw-5393684
This update corrects a formatting issue where the total time on timesheet lists wasn't displayed correctly after a refresh. The fix ensures that the total time is formatted consistently, regardless of whether the user is viewing the timesheet in list or grid view. This improves the accuracy and usability of the timesheet reporting feature.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget…
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107203 Forward-Port-Of: odoo/enterprise#107006
This update ensures the OCR functionality correctly processes receipts, addressing a previous bug where it wasn't available. Previously, setting an invoice as a receipt wouldn't trigger the 'Digitize document' button. This fix ensures accurate tax calculations and proper OCR processing for receipt documents, resolving issues with incorrect tax application and preventing the digitization button from working.
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
This update resolves an issue where tests were unintentionally executed twice within the delivery ups integration module. This improvement ensures more efficient testing and reduces potential performance impacts. The fix focuses on streamlining the testing process for a more reliable system.
Original PR description
Forward-Port-Of: odoo/enterprise#106911
This update resolves a problem where the report date filter misbehaved in faketime build environments. The fix skips tests specifically for faketime builds, as the issue is isolated to this environment and will be addressed in future versions. This ensures reports function correctly for all users.
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 resolves an issue where rental orders were failing due to an incorrect customer name being used. The fix ensures that the system uses the customer's `display_name` instead, which is a reliable and consistent field, preventing errors and improving order processing. This ensures accurate customer information is displayed in rental schedules.
Original PR description
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to…
Steps to produce: --- - Install `sale_renting` and `contacts` modules. - Go to contact and open `yourcompany` record. - Add a new contact of type Delivery and save (leave the name empty). - Go to Rental > New Order. - Select YourCompany, Delivery as the customer. - Add a rental product and confirm the order. - Open the Schedule view. Traceback: --- `TypeError: sequence item 0: expected str instance, bool found`. Root cause: --- - At [1], the system tries to use the customer's name when computing the display name. However, in this case, the delivery contact has no name, resulting in a False value. This False value is then included in the description list, causing the TypeError when joining the sequence. Solution: --- - Use the partner's `display_name` instead of `name`. The `name` field can be `False` in some cases. The `display_name` field is a computed field that always provides a valid, formatted string by using fallback values such as the company name, parent name, or contact type. This ensures consistency and prevents errors [1] https://github.com/odoo/enterprise/blob/f5fea1d7b40e42b7bc1c323cc9613b1aa347da09/sale_renting/models/sale_order_line.py#L61 opw-5914084 ---
This update resolves a misleading warning appearing in the Belgian tax reports. The issue stemmed from a false negative value being generated by carryover lines, which are not intended to produce negative values. This change ensures the reports accurately reflect financial data.
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
11 changes
Resolved issues and error corrections
This update resolves an issue preventing a key test case for website redirection functionality. The fix ensures the test runs correctly even without the standard demo data, which previously required a specific user group to be enabled. This change is limited to versions 18.2 and earlier.
Original PR description
Commit f86f6f6a3dc6bbeb8c68308aab2462b9c7bb935d (6th February 2026) added the test test_website_force_domain_redirect but it doesn't work without demo data because it was requiring "website.group_multi_website" group to be enabled. Fix: add the group for the test case in case it's not enabled. runbot-[238897](https://runbot.odoo.com/odoo/runbot.build.error/238897) opw-5441957 Note: this was noticed in saas-18.3 forward port so this is only necessary up to saas-18.2 version. Forward-Port-Of: odoo/odoo#248304
This update resolves a delay in reading data from Toledo scales. Previously, the system waited up to one second for a response. Now, it reads the scale data until a carriage return character is received, eliminating this delay and improving responsiveness. This ensures more accurate and timely data collection from these scales.
Original PR description
Before this commit, the `_get_raw_response` method would wait until the read timed out (1 second) before returning the response. After this commit, for the Toledo scale we instead read until we reach a `\r` character, which is at the end of the response. This eliminates the 1 second delay. Enterprise: https://github.com/odoo/enterprise/pull/107241 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a display issue within the Italian tax module (l10n_it_edi) where TC-XX codes weren't shown alongside pension fund type names. Previously, all other selection fields displayed codes first, but this field was an exception. This ensures accurate and consistent reporting for Italian businesses.
Original PR description
How to reproduce: - Install the l10n_it_edi module - (Create and) switch to an Italian company - Go to the form view of any tax - In Advanced Options, click on the Pension fund type field The problem: The codes are not displayed before the names of the pension fund types Why: All other selection fields in the Advanced Tab shows the code before the name (Exemple: Tax category code, Exoneration, ...). The Pension fund types field was the only one that did not opw-5914302 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247410
This update fixes a potential issue where translation mapping could fail when the number of translated terms didn't perfectly match the base language. Now, the system gracefully falls back to the base language's values, preventing errors and ensuring more accurate translations. This improves the reliability of our translation process.
Original PR description
When the number of translated terms differs between the base language and its translation, fall back to the base value instead of attempting to map terms. This avoids potential errors and incorrect translation mappings. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor bug in the HTML editor component that was causing errors when the focus element was missing. The fix uses a technique called 'optional chaining' to safely access the previous sibling, preventing the traceback and ensuring smoother editor functionality. This improves stability and reliability of the HTML editor.
Original PR description
Before this commit: in rectifySelection, the focusTarget can be null and causing an error when calling the previousSibling After this commit: now we do an optional chaining(?.) on previousSibling task-5481248 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent test was causing build errors due to inconsistent leave requests, particularly when coinciding with legal holidays. This commit corrects the test to ensure leave is always requested for the intended date, resolving the build issues and improving test stability. This change ensures accurate leave processing during testing.
Original PR description
The test 'test_holiday_responsible_refuse_leave' is creating build errors in the runbot, it requests a leave for the current day, which can fall on a legal day off, and will then result in an error. This commit ensures the leave is consistently requested for a correct date. https://runbot.odoo.com/odoo/runbot.build.error/237917
This update corrects a technical issue that was preventing Odoo e-invoices from passing PDF/A-3 validation. The previous code incorrectly stored file sizes as text strings instead of numbers, leading to validation errors. This fix ensures our e-invoices meet industry standards for archiving, improving compliance and reducing potential issues with document processing.
Original PR description
The `/Size` parameter in embedded file `/Params` was being set using `NameObject` instead of `NumberObject`, resulting in the size value being stored as a PDF Name Object (e.g., `/19410`) rather than a numeric integer (`19410`).
This causes PDF/A-3 validators to report zero-size or invalid attachments, breaking compliance with ISO 19005-3 (PDF/A-3A).
Steps to reproduce:
- Generate an e-invoice PDF with XML attachments (e.g., Factur-X)
- Validate the PDF with veraPDF or Adobe Acrobat Preflight
- Embedded file size is reported as zero or invalid
Fix:
```diff
- NameObject('/Size'): NameObject(f"/{len(attachment['content'])}"),
+ NameObject('/Size'): NumberObject(len(attachment['content'])),
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where users could trigger errors when entering non-numeric values in the serial/lot number field. By changing the field's input type to 'number' and adding a keypress handler, the system now correctly validates input, preventing errors and ensuring reliable serial number generation.
Original PR description
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots…
Issue before this commit: ========================= When generating serial/lot numbers, if a user enters a `string value (e.g. "dhha" or ".")` in the `Number of SN` field of the Generate Serials/Lots wizard, a traceback is raised: `InvalidNumberError: "dhha" is not a correct number`. Steps to Reproduce: ========================= - Install the "stock" module. - Create a receipt for a serial-tracked product. - Open the detailed operations. - Click on "Generate Serials/Lots". - Enter a string value in the "Number of SN" field. Result: A traceback is raised with: InvalidNumberError: `"dhha" is not a correct number.` Cause of the issue: ========================= The [next_serial_count input](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/lots_dialog.xml#L36) field is defined as type="text", which allows users to enter string values, even though the field represents a numeric count. The value is later processed using [parseInteger](https://github.com/odoo/odoo/blob/17.0/addons/stock/static/src/widgets/generate_serial.js#L33), which throws an error when the input is not a valid integer string, [Here](https://github.com/odoo/odoo/blob/17.0/addons/web/static/src/views/fields/parsers.js#L139). With This Commit: ========================= The input type is changed from type="text" to type="number", ensuring that only numeric values can be entered. This prevents invalid input and avoids the traceback when generating serial or lot numbers. Additionally, a `t-on-keydown` handler is added to prevent entering a `dot (.)`, ensuring that only integer values are allowed. Forward-Port-Of: odoo/odoo#248221
This update corrects a bug where nodes containing directives (like 'groups') were incorrectly identified as translatable. This prevented proper translation of certain elements within the Odoo interface. The fix ensures that only standard elements are considered for translation, improving the accuracy of translated content.
Original PR description
Nodes with directives must not be included inside a translatable span. But the function `translatable` missed the directive `groups` (without `t-`), and the class `o_translate_inline` should only override the predicate about the element's tag. Forward-Port-Of: odoo/odoo#246354
This update resolves a discrepancy in the scale certificate checksum, aligning it with a recent fix implemented in the core Odoo platform. This ensures accurate verification of the certificate and maintains compliance standards. The change was driven by a community-developed improvement.
Original PR description
This commit simply updates the expected scale checksum after the fix in the community PR odoo/odoo#248413.
This update corrects a bug in the timesheet approval reminder email. The email was referencing an outdated action, which caused it to fail. This change ensures the approval reminder email functions correctly, prompting timely approvals for timesheets.
Original PR description
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in…
### Issue: The action used in the ` timesheet approval reminder` email template refair to a non existing action. ### Cause of the issue: The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461 Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45 The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action: https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198 opw-5890269
3 changes
Resolved issues and error corrections
This update resolves an issue where attendance managers couldn't correctly edit the attendance records of their subordinates. The fix ensures both managers and officers can now modify attendance data, improving workflow efficiency. The changes also included enhanced testing for greater reliability.
Original PR description
The commit https://github.com/odoo/odoo/commit/d115cca1296c0bd20a2875bdaadf2a9136c33dda introduced the opportunity for attendance managers to edit their subordinates attendances, but the condition was lacking parenthesis, leading to an unexpected behaviour. This commit changes the condition so that it is possible both for a manager and an officer to do the edition. It also rewrite the tests in order to be more thorough. No related task
This update resolves an issue where test runs were repeatedly generating unnecessary assets, slowing down the testing process. By adding the 'studio_assets' bundle to the pregeneration list, tests now run more efficiently and reliably. This improves overall development speed and stability.
Original PR description
During tests runs, lazy loaded assets are generated on the fly, and eventually multiple hundred of times (i.e. +/- 150 times on runbot). This commit adds the `web_studio.studio_assets` bundle to the pregeneration list to avoid regenerating during tests runs.
This update resolves an issue where DHL shipping rate requests failed when submitted late in the day. The fix adds a 'next business day' flag to the request, ensuring rates are calculated correctly and preventing errors related to unavailable pickup dates. This improves the reliability of DHL shipping calculations.
Original PR description
Before this commit, there was an issue when trying to get the rates for DHL shipping late in the day. The issue happened because `plannedShippingDate` fell outside of the working hours. This commit adds the nextBusinessDay flag for the rating request to avoid the error. Error: ``` Product not found 996: The requested product(s) not available for the requested pickup date. Process ID associated for this transaction') ``` opw-5393684