Thursday, February 26, 2026
31 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where the Odoo system would crash if Avatax company credentials weren't found. The fix prevents a crash by handling the missing credentials gracefully within the system's processes, ensuring smoother operation for users relying on Avatax integration.
Original PR description
When `_find_avatax_credentials_company` returns `None`, `_get_avatax_service_params` crashes accessing `.avalara_commit` on it. `_find_avatax_credentials_company` should probably return an empty `res.company` recordset when it cannot find a company, but for stability reasons we won't change the return value and instead fix it locally in `_get_avatax_service_params`. opw-5939708 Forward-Port-Of: odoo/enterprise#108192
A recent update was causing the 'Publish & Send' button to disappear in the scheduling interface. This fix removes a temporary workaround that was inadvertently hiding the button. The change ensures the button remains visible when scheduling shifts, resolving a reported issue.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108333This update fixes an issue where sales order statuses were displayed in an incorrect alphabetical order within the Kanban view. The change ensures that statuses like 'Cancelled', 'Quotation', 'Sale Order', and 'Quotation Sent' appear in the logical order expected by users. This improves the clarity and usability of the sales order management process.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248776
This update corrects a formatting issue in the Eco Voucher export file, ensuring it aligns with the specifications required by the Monizze payment system. This resolves a potential compatibility problem, guaranteeing accurate data transfer and preventing errors in the voucher processing workflow. It's a necessary adjustment to maintain seamless integration with our financial partners.
Original PR description
This commit realigns the xlsx header with what's expected by Monizze for the eco voucher export. Forward-Port-Of: odoo/enterprise#108668
A small typo in the Mercado Pago webhook processing was causing payment failures. This update corrects the typo, ensuring that Mercado Pago payments are now processed correctly and reliably. This resolves a technical issue preventing successful transactions.
Original PR description
On receiving a message from Mercado Pago on the webhook, there was a typo causing a traceback and preventing the payment from being confirmed. This commit corrects the typo. opw-5953884 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the location selector would unexpectedly gain focus when no delivery location was initially selected. This ensures a smoother user experience by preventing distractions and improving usability when a location hasn't yet been chosen.
Original PR description
Forward-Port-Of: odoo/odoo#250680
This update resolves a technical issue that prevented users from correctly replenishing products when multiple 'Buy' or 'Manufacture' routes were configured. The fix ensures that only one default route is selected, preventing a system error and allowing replenishment to function as expected. This improves the reliability of the product replenishment process.
Original PR description
Followup to previous fix: 705e27a2d3d9e3c4d075a1e8fb599333a504a316 If the user configured his database with more than one Buy or Manufacture route, the `_get_route_domain` would trigger a Singleton…
Followup to previous fix: 705e27a2d3d9e3c4d075a1e8fb599333a504a316
If the user configured his database with more than one Buy or Manufacture route, the `_get_route_domain` would trigger a Singleton Error.
# Steps to Reproduce:
- Create new Manufacture Route:
- Create new Warehouse W2
- Create new 'Manufacture 2' route (no rule yet)
- Go to the 'Manufacture' route
- Select the new rule for W2, expand popup
- Update the route to 'Manufacture 2'
- Create new Product P
- Storable
- Create Basic BoM
- Product form -> Actions wheel -> Replenish => Singleton Error
OPW-5960493
---
## Configuration
<img width="1844" height="628" alt="image" src="https://github.com/user-attachments/assets/b90c070c-4af5-427c-bd3d-79904a7881a0" />
## Traceback
```
RPC_ERROR
Odoo Server Error
Occured on 102180409-19-0-design-theme.runbot119.odoo.com on model product.replenish on 2026-02-25 08:12:03 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http.py", line 2273, in _serve_db
return service_model.retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 185, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http.py", line 2328, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 2543, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/web/models/models.py", line 1964, in onchange
defaults = self.default_get(missing_names)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/purchase_stock/wizard/product_replenish.py", line 12, in default_get
res = super().default_get(fields)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/stock/wizard/product_replenish.py", line 77, in default_get
res['route_id'] = self.env['stock.route'].search(self._get_route_domain(product_tmpl_id), limit=1).id
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/purchase_stock/wizard/product_replenish.py", line 92, in _get_route_domain
domain = super()._get_route_domain(product_tmpl_id)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/addons/mrp/wizard/product_replenish.py", line 51, in _get_route_domain
domain = Domain.OR([domain, Domain('id', '=', manufacture_route.id)])
^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/orm/fields_misc.py", line 114, in __get__
raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.route(6, 20)
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250580This update fixes a minor issue where the website's image carousel navigation wasn't correctly functioning for right-to-left languages like Arabic. By adding a specific HTML attribute, the carousel now correctly displays the next and previous images based on the language direction, ensuring a consistent user experience across different languages.
Original PR description
Some libraries expect to find the language direction on the HTML element (e.g. Bootstrap). As we didn't set it, there were some issues. For instance on the website: - set the website language to some RTL language (e.g. Arabic) - drop an image gallery snippet and save - navigate with the keyboard to the carousel and start using the arrows to switch images => Pressing left should show the _next_ image, and pressing right should show the _previous_ image (contrary to LTR languages). This is illustrated by the image indicators at the bottom of the carousel (the 1st image is on the right, the last image on the left). But without `dir="rtl"` on the HTML element, the arrows keep their LTR behavior: pressing left goes to the previous image, and right to the next image. task-5109547 Forward-Port-Of: odoo/odoo#250257 Forward-Port-Of: odoo/odoo#240611
This update fixes a bug that occurred when users deleted the 'Standard 40 hours/week' working schedule. The 'Payroll: Update data' cron job then encountered an error because the linked ID was no longer present. This ensures payroll data updates continue to function correctly after schedule deletions.
Original PR description
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us When the ``Standard 40 hours/week`` working schedule is deleted and the ``Payroll: Update data`` cron runs, a traceback is raised. For…
*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us
When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.
For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron
Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std
ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
<field name="name">United States: Employee</field>
<field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
<field name="country_id" ref="base.us"/>
</record>
```
The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.
sentry-7166574553
Forward-Port-Of: odoo/enterprise#106950This update resolves an issue where duplicate receipts were appearing on Odoo Point of Sale tickets. The problem stemmed from a system error triggered by blocking the action URL in the browser, leading to the same confirmation being sent multiple times. This ensures accurate receipt generation for customers.
Original PR description
This PR fixes two same worldline receipts appearing on the point of sale ticket Reproduced by blocking the action url in browser but not the event one. Websocket fallback action is sent and the confirmation is sent both to the longpolling and websocket, resulting in _setCardAndReceipt method being called twice. Forward-Port-Of: odoo/enterprise#108570
This change addresses a bug that caused an error when rendering UI views, specifically related to how data was being accessed. The fix ensures that a 'None' value is assigned before attempting to use a variable, preventing the UnboundLocalError. This improves the stability and reliability of the UI.
Original PR description
When syntax error will raise ``node`` will not assign. So, assign ``None`` before error will surpess. Note:- found it during testing. ``` Traceback (most recent call last): File…
When syntax error will raise ``node`` will not assign. So, assign ``None`` before error will surpess.
Note:- found it during testing.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2273, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2328, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2543, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 32, in call_kw
return call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/web/models/models.py", line 113, in web_read
values_list: list[dict] = self.read(fields_to_read, load=None)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6686, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1746, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1917, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4952, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 366, in _compute_invalid_locators
if invalid_locator := assess_locator(source, spec):
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 330, in assess_locator
if node is None:
UnboundLocalError: local variable 'node' referenced before assignment
```
opw-5956964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250589This update resolves an issue where products weren't automatically marked as 'published' on the website when assigned to a category. The fix ensures that category assignments correctly update the product's website visibility, preventing products from being hidden. This improves the user experience for displaying products on the website.
Original PR description
Error: AssertionError: False is not true self.assertTrue(product.website_published) Cause: Commit https://github.com/odoo/odoo/commit/ca198cfc7c41a8c15b2734518016007aa1c16457 relies on _onchange_public_categ_ids to set website_published=True when a category is assigned. Two issues: 1. website_published was not in the dialog form view, so its onchange value was never tracked or sent to the server on save. 2. The tour clicks Save before the onchange response is received, so the product is saved without website_published=True. Fix: - Add website_published as an invisible field in the dialog form view so its value is tracked and sent on save. - Wait for the category badge to appear before submitting, ensuring the onchange has completed before save. runbot-237976 Forward-Port-Of: odoo/odoo#250473 Forward-Port-Of: odoo/odoo#249027
This update ensures self-order transactions in the POS system have the same robust data validation rules as standard POS orders. This enhances data accuracy and reliability, reducing potential errors and improving the overall transaction process. It aligns the self-order system with established best practices.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order. Forward-Port-Of: odoo/enterprise#108224
This update resolves intermittent failures in website background image tests due to network delays. By proactively loading and caching images, the commit significantly reduced test execution time from 26.7 seconds to 15.4 seconds. This improves website performance and user experience.
Original PR description
Background option tests were failing in nightly builds sometimes because of the network hang. This commit aims to fix the errors by prefetching the images and caching them. Here's the `background_option` test suite and the total time it took to finish with a throttled network (fast 4G) before and after the commit, respectively. | Before commit | With commit | |--------|--------| |<img width="610" height="224" alt="image" src="https://github.com/user-attachments/assets/a98fb1fe-27a1-4f73-901f-7d7ade8ecd86" />|<img width="610" height="224" alt="image" src="https://github.com/user-attachments/assets/c9ed0948-8112-4f2b-b843-c887c9302b76" />| | 26.7 (s) | 15.4 (s) | runbot-237641 Forward-Port-Of: odoo/odoo#250578 Forward-Port-Of: odoo/odoo#249074
This update corrects a technical issue where certain Intrastat codes (99450000, 99500000, 99600000, and 99700000) were incorrectly marked as expired. The fix ensures these codes remain active, aligning with official Belgian regulations outlined in the Intrastat manual. This ensures accurate reporting for international trade data.
Original PR description
99450000, 99500000, 99600000 & 99700000 were erroneously expired. They are still active : https://www.nbb.be/doc/dd/onegate/data/intrastat_manual_basis_en.pdf page 13 Forward-Port-Of: odoo/enterprise#108451
This update fixes a technical issue that was preventing accurate payslip calculations for employees with specific salary rules. The problem occurred when a user hid a salary input field, causing an error during payslip generation. The fix ensures that these hidden inputs are correctly ignored, resolving the calculation problem.
Original PR description
**Steps to reproduce** - Have a salary rule - Condition based on: Salary Input - Input on: Employee - On the employee form, click on "Add inputs" in the Payroll tab - Add an input - Enter a value - Click on "Inputs" to fold the section and hide the input - Try to compute a new payslip for this employee, error: `ValueError: invalid literal for int() with base 10: 'separator_1'` **Cause** By default, the separator doesn't have a `value` key, but after the first interaction to hide its elements, it is added to keep track of the folded state (see `_toggleSeparators` in `web`). **Solution** Ensure separators are ignored. opw-5928247 Forward-Port-Of: odoo/enterprise#107326
This update resolves a technical issue where a new view within the POS appointment module was interfering with other Odoo modules. The fix adds a 'primary' mode to the new view, restricting its use to the POS appointment functionality and preventing conflicts.
Original PR description
The list view in pos appointment would replace the original list view on calendar event and break other modules. This PR will add the `primary` mode for the new view so it is only used inside the POS Runbot Error: [234914](https://runbot.odoo.com/odoo/runbot.build.error/234914)
This update fixes a confusing error message users received when generating leads without sufficient credits. Instead of a generic message, the system now correctly indicates when credits are unavailable, providing a clearer experience for users. This ensures a smoother process for lead generation within the CRM.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047 Forward-Port-Of: odoo/odoo#250433
This update corrects a technical issue preventing invoices sent via Peppol from passing validation. The system was incorrectly using 'UNSPSC' instead of the required 'TST' code for the commodity classification scheme. This change ensures compliance with Peppol standards and allows invoices to be successfully processed.
Original PR description
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**.…
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**. **Observed behavior:** * Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”* * The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`. **Cause:** * The `listID` attribute was set to the literal string **'UNSPSC'**. * According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'. **Fix:** * Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node. * Update and extend tests to validate the correct scheme identifier. * Same for CPV code from the documentation i's code is also changed to 'STI'. ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ opw-5948723 Forward-Port-Of: odoo/odoo#249788
This update resolves an issue where the SRI payment method wasn't correctly applied to invoices for POS orders paid entirely with gift cards in Ecuador. The fix automatically sets the SRI payment method (code '01') when no other payments are associated with the order, ensuring accurate invoice generation and compliance.
Original PR description
When a POS order has no payment associated (e.g. when the order is fully paid with a gift card), the SRI payment method was not set on the invoice Steps to reproduce: ------------------- * Create a PoS in Ecuador with the l10n_ec_edi_pos module installed * Create a gift card program and some gift cards * Create a PoS order and pay it fully with a gift card and invoice it > Observation: You get an error saying that the SRI payment method is required Why the fix: ------------ When setting the SRI payment method on the invoice, we check if there are more than 1 payment associated with the order, and if not we fallback on the SRI payment with code "01" opw-5432004 Forward-Port-Of: odoo/enterprise#107966
This update corrects a technical issue where the guest recordset in Odoo's AI responses wasn't properly linked to the current environment. This prevented access to necessary context and could lead to errors. The fix ensures that the guest recordset is correctly bound to the new environment's context, resolving this problem and improving response reliability.
Original PR description
## Fix Summary When generating responses, the guest recordset must be re-bound to the new environment's context to avoid losing any context. Using dict(env.context, ...) ensures that existing context values are preserved while adding the guest to the env.
This update fixes an issue where contacts without names or emails in Odoo's chatter interface would display as 'Unnamed'. Now, when a contact lacks a name and email, the system will automatically show their display name instead, providing a more user-friendly experience. This ensures consistent and clear recipient identification across all Odoo apps.
Original PR description
Steps to reproduce =============== 1. Create a contact of type invoice address without name and email. 2. Go to any app with chatter. 3. Add this user to the recipient ----> Only the blue tick will be visible (recipient name will be empty) After this commit, we will use the display_name as a fallback to show in the chatter. Forward-Port-Of: odoo/odoo#240657 Forward-Port-Of: odoo/odoo#213545
This update resolves an issue where the agent subtitle in the chat window was consistently empty. The fix adds a mechanism to store and display the agent's subtitle, ensuring consistent and informative chat communication. This improves the user experience by providing context within the chat interface.
Original PR description
The chat subtitle is always empty, whether the agent description is set or not. Even though PR - https://github.com/odoo/enterprise/pull/93612 (merged earlier in saas-19.1 version) mentions that the subtitle should be visible. It is not visible because we are always getting `undefined` over here - https://github.com/odoo/enterprise/blob/38e66c4607cb1dad93f17591383c39d8c37c6e0b/ai/static/src/discuss/thread_patch.js#L10 This commit fixes the issues by extending the stored fields with subtitle and adding a default message if subtitle is missing. Something similar is implemented in this commit (merged in master) - 9bdec04a7e6f127f6a5dfbf975f7ae0d7e89bc1a Task-5916227
This update resolves an issue where the Discuss app would display a horizontal scrollbar on smaller screens. The fix adjusts how the app's layout adapts to different window sizes, ensuring a consistent and usable experience across devices. This improves the overall user experience for the Discuss app.
Original PR description
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on…
Before this commit, when Odoo browser had a relatively small width but still desktop width, the Discuss app had sometimes an horizontal scrollbar. Steps to reproduce: - Open General with Demo data on 1080p monitor - have window take slightly below half of screen width => The Discuss app has horizontal scrollbar, from sidebar non-compact, message list, and the member panel all open at once. This horizontal scrollbar comes from the General demo data that has a sub-thread preview from the 1st message. A sub-thread preview has a max-width of 400px, which shouldn't be an issue on itself. However due to parented container not having `min-width: 0`, it didn't want to shrink lower than this max-width. This commit fixes the issue with `o-min-width-0` on the parented container to make sure this can shrink lower than the sub-thread preview's max width of 400px. Task-5956698 Before / After <img width="882" height="635" alt="Screenshot 2026-02-20 at 16 36 14" src="https://github.com/user-attachments/assets/516b66a1-f8d2-4ee9-b62f-6d94dfe98d11" /> <img width="884" height="637" alt="Screenshot 2026-02-20 at 16 37 07" src="https://github.com/user-attachments/assets/987f418c-f7e2-477b-ae9c-6c68d6a21ec5" /> Forward-Port-Of: odoo/odoo#249846
This update resolves an issue where the salary calculator incorrectly used a default full-time calendar, leading to inaccurate calculations when simulating employees with different work hours. The fix ensures the calculator now correctly applies the selected work schedule (e.g., 40h/week or 20h/week) for accurate salary simulations. This improves the reliability of payroll calculations.
Original PR description
Steps to reproduce: 1- Go to Payroll > Employees > Salary calculator 2- Put a yearly cost of 10000 3- Select the "40h/week calendar" 4- Check the yearly cost 5- Change to "20h/week calendar" Cause of the bug: _get_version inside ContractSalaryOffer would take the default calendar from the version if it exists (in our case it will always be the full time for the simulation employee) Fix done: Keep the condition as it is for normal offers, and for simulation offers change the default to the selected resource calendar task-5431216 Forward-Port-Of: odoo/enterprise#103159
This update resolves a visual glitch in the Email Marketing app where test emails were incorrectly showing as 'removed' in related contact records' Chatter. The fix ensures that test messages are automatically removed when sent, preventing this misleading display and maintaining a clean user experience. This improves the reliability of test emails.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a mailing campaign - Set its recipients to Contact - Click on the test button to send a test mail to any mail - Go to the first contact…
**Steps to reproduce:**
- Go to Email Marketing app
- Create a mailing campaign
- Set its recipients to Contact
- Click on the test button to send a test mail to any mail
- Go to the first contact record
- Chatter will show `This message has been removed` message
**Issue:**
Previously, message created for testing were ignored by the Chatter as they were empty. As we now keep empty messages visible but with removed content display, they shows up on related records.
```py
record = self.env[mailing.mailing_model_real].search([], limit=1)
```
**Fix:**
Ensure the related messages are unlinked at the same time as the test mail in `send_mail_test` by setting `is_notification` to `False` to trigger the `unlink` logic.
```py
def unlink(self):
# cascade-delete the parent message for all mails that are not created for a notification
mail_msg_cascade_ids = [mail.mail_message_id.id for mail in self if not mail.is_notification]
res = super(MailMail, self).unlink()
if mail_msg_cascade_ids:
self.env['mail.message'].browse(mail_msg_cascade_ids).unlink()
return res
```
related: https://github.com/odoo/odoo/commit/21f92550f83cbd38df2c223c65c61bd16dc8e2b0
opw-5502787
Forward-Port-Of: odoo/odoo#247805This update resolves an issue where payment status information wasn't being displayed correctly. The fix replaces a problematic data field with a more reliable identifier, ensuring accurate payment status updates are consistently retrieved. This improves the reliability of payment tracking within the system.
Original PR description
Currently `this.props.record.data.id` returns `undefined` which results in an empty results dict and thus None value on the status. To fix this we switch from using the `data.id` to `resId` No Task ID
This update resolves an issue where the PIS status for batch payments wasn't updating correctly after refreshing. The fix ensures the correct database ID is used when fetching the status, guaranteeing accurate updates for SEPA credit transfers and similar payments. This improves the reliability of payment status reporting.
Original PR description
When clicking the refresh button next to the PIS status field on a batch payment (e.g., paid with SEPA credit transfer), the status is cleared and no new value is set. This occurs because `onClickFetchStatus` makes an ORM call to fetch the status using `this.props.record.data.id`, which is `undefined`. This commit fixes the issue by correctly using `this.props.record.resId` to pass the database ID to the RPC call. no task-id
This update resolves an issue where the stock valuation report was displaying inaccurate unit costs due to floating-point precision problems. The fix ensures more reliable calculations by addressing potential rounding errors, preventing inflated or negative values. This improves the accuracy of inventory reporting.
Original PR description
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a…
Problem: In the `stock.avco.report`, there is a chance for floating point inaccuracies to cause avco unit cost to inflate. This occurs specifically when the remaining quantity is calculated to be a positive number extremely close to 0. There are also issues with negative avco value that are tangential to this error. Solution: We will mirror the iterative logic from `_run_avco`, being sure to account for whether we have moved from negative quantity to positive or vice versa. Also, before calculating avco value as `total_value / total_quantity`, we will ensure `total_quantity` is not a floating point number very close to 0 to avoid unit cost inflation. Steps to replicate (Runbot 19): Have storage locations enabled to make this easier to test 1. Product with tracked inventory, avco perpetual valuation, non-zero cost 2. Set the on hand quantity to -0.3 Units 3. Set the on hand quantity to -0.2 Units 4. Set the on hand quantity to 0 Units (A well-known python quirk, that .1 + .2 = 0.30000000000000004) Go to the stock report and inspect the unit cost history for the product, note 1. The nonsense Unit Cost on the top row 2. The negative Unit Cost on the 2nd row Note to reviewer: I discussed this issue briefly with dafr, who pointed out that there are further adjustments to come with the `_run_avco` method, and several other issues with this report that are not addressed by this PR. However, the problems with this report are affecting a customer so we'd like to push these fixes forward for now. opw-5430300 Forward-Port-Of: odoo/odoo#245141
This update fixes the XML templates used for Dutch tax reporting (SBR and ICP) to align with the latest 2026 version of the Dutch taxonomy. This ensures accurate reporting for our Dutch customers, complying with local tax regulations. The change is a technical update to maintain compliance.
Original PR description
Fix the xml SBR and SBR ICP file template for the 2026 version of dutch taxonomy Documentation: https://www.sbr-nl.nl/werken-met-sbr/taxonomie/documentatie-nederlandse-taxonomie task-5974129
This update resolves an issue related to how sick leave is tracked in Belgium. Previously, complex calculations caused problems with matching sick leave entries. The change moves the specific Belgium logic to a localized module, addressing a prior issue and ensuring accurate sick leave reporting.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code and we move the BE specific changes to the BE localization module. To do this, we move the logic in a function which we will override inside that module (see related Enterprise PR). Task: 5472538 Enterprise PR: https://github.com/odoo/enterprise/pull/105776