Thursday, February 26, 2026
18 changes · 19.0
Enhancements to existing features
Belgian VCS-OGM payment references are now recognized even when they do not start with the usual plus or asterisk symbols. This helps matching and processing of bank transactions that use the common slash-separated format, reducing manual follow-up.
Original PR description
The aim of this commit is handling the case where the Belgian VCS-OGM is not starting with + or *. Before this commit, transactions without one of these 2 characters wasn't marked as structured. With this commit, we do handle this format as well: xxx/xxxx/xxxxx task-5403947 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The delivery location selector now avoids moving focus when no pickup or delivery location has been selected. This prevents confusing page behavior during checkout and makes the selection flow smoother for customers.
Original PR description
Forward-Port-Of: odoo/odoo#250680
Miscellaneous changes
This pull request makes a small documentation-only update as part of a technical training exercise. It does not appear to change any Odoo business features or day-to-day user workflows.
Original PR description
Hi, just a first PR!
The Sales kanban view now shows order statuses in their intended business sequence when grouped by status. This prevents confusing alphabetical ordering such as cancelled orders appearing before quotations, making sales pipelines easier to read.
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 fix prevents Odoo from crashing when it encounters a syntax error while checking view definitions. Instead of showing an unrelated internal error, the system can handle the original issue more reliably, improving stability during testing and view validation.
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#250589Installing the Guatemala localization could fail because city data depended on an address feature that was not loaded. The city data has been moved into a separate companion module so businesses can install the localization reliably without changing stable-version dependencies.
Original PR description
**Steps to reproduce:** - Create a new database. - Install the `l10n_gt` module. **Error:** `KeyError: 'res.city' ` **Root Cause:** In PR [1], the file `res.city.csv` was added in the `l10n_gt` module, which relies on the `base_address_extended` module, but this dependency is not declared in the manifest file. **Fix:** This commit adds a new bridge module between `l10n_gt` and `base_address_extended`, and moves `res.city.csv` into this new module (`l10n_gt_city`). This approach is chosen because modifying dependencies in a stable version is not recommended. [1]: https://github.com/odoo/odoo/pull/247719
This fixes cases where editable input fields could become too narrow or overflow when browsers calculated field width differently. The width is now adjusted based on the actual field styling and browser behavior, making forms and lists display more consistently for users.
Original PR description
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and…
Before this PR, `autoresizeInput` used a fixed buffer of `5px` to compensate for input borders. This caused incorrect sizing when inputs had thicker borders, leading to overflow issues. Safari 16 and earlier versions did not include padding and border in `scrollWidth`. To work around this, browser detection via regex was used to add a hardcoded extra value. A similar issue appeared in Firefox 145, where scrollWidth also excluded padding and border, causing inputs to overflow again. After this PR, The buffer is no longer hardcoded. The border width is now calculated dynamically and applied correctly to the final width. Browser sniffing has been removed entirely. Instead, the logic detects at runtime whether scrollWidth includes padding; if not, the missing padding is added to the computed width. This makes the behavior consistent across browsers and prevents overflow without relying on user agent checks. task-[5412025](https://www.odoo.com/odoo/project/1519/tasks/5412025) Forward-Port-Of: odoo/odoo#249197 Forward-Port-Of: odoo/odoo#241315
The website Products block now shows carousel navigation arrows at the correct size when using the full-width layout. This improves the visual quality of shop pages and prevents a distracting display issue for visitors.
Original PR description
**Problem:** When a "Products" block on the website is set to the full-width (extended) content option, the previous/next carousel navigation arrows render at an abnormally large size instead of…
**Problem:** When a "Products" block on the website is set to the full-width (extended) content option, the previous/next carousel navigation arrows render at an abnormally large size instead of their intended compact appearance. **Steps to reproduce:** 1. Go to Website > Edit a page 2. Add a "Products" block 3. Set the content width to the rightmost (full-width) option 4. Observe the carousel navigation arrows **Current behavior:** The carousel navigation arrows appear oversized and stretched. **Expected behavior:** The carousel navigation arrows should display at their normal size. **Cause of the issue:** The carousel control buttons have a `transform: scaleX(0.2)` to counteract the inner chevron icon's `transform: scaleX(5)`, keeping the visible arrow at its intended size. In full-width mode, a positional `transform: translateX(...)` is applied to the same parent element. Since `transform` is a single CSS property, this completely overrides the `scaleX(0.2)`, leaving the chevron's `scaleX(5)` unopposed and causing the arrows to render at 500% of their expected width. **Fix:** Both the positional offset and the scale compensation must coexist in the same `transform` declaration on the parent. Extracting the scale value into a CSS variable allows the full-width rule to reference it directly, combining `translateX()` and `scaleX()` in one `transform` without duplicating the magic value. This also preserves RTL compatibility, as `transform: translateX()` is correctly mirrored by rtlcss, unlike the standalone `translate` property. opw-5917549
This update resolves a technical issue where the Odoo Enterprise system would crash if Avatax company credentials were not found. The fix ensures stability by handling the missing credentials gracefully within the system's code, preventing unexpected errors. This improves the reliability of 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
This update resolves a bug where the 'Publish & Send' button was hidden in the 'Schedule by Resource' view. The previous fix incorrectly added a context variable, causing this issue. This change removes the problematic condition, restoring the button's visibility and functionality.
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 resolves an issue where a 100% discount on German POS Cert orders would cause an error. The change ensures the system handles this scenario correctly, preventing disruptions to order processing. This improves the reliability of the German POS Cert module.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429 Forward-Port-Of: odoo/enterprise#108561
This update resolves a bug where the booking management page wouldn't refresh correctly. The fix ensures the booking view renders properly after a page refresh, improving the user experience for managing appointments within the POS system. This prevents disruptions and ensures accurate booking data is displayed.
Original PR description
Steps: ----- - Install pos_appointment and pos_urban_piper modules. - Open a session for an UrbanPiper-configured POS. - Open the Manage Booking page. - Refresh the page. Issue: ----- - The booking view is not rendered after a page refresh. Cause: ----- - An awaited request in the posStore setup caused the `ActionComponent` not to be rendered yet when the `doAction` was called. Fix: ----- - First render the `ActionComponent`, then fetch the action data, and finally call `doAction`, so the action is executed seamlessly without interruption. Task-5713125 Forward-Port-Of: odoo/enterprise#105629
This update resolves a technical issue preventing the scale certification module from correctly processing data sent by the new event manager. Previously, readings were reported as 'results' instead of actual values, causing scale readings to sometimes display as zero. This fix ensures accurate scale data reporting.
Original PR description
This PR fixes the lack of compatibility with the new event manager code sending result instead of value, fixing the weighing stuck at 0 in some situations Forward-Port-Of: odoo/enterprise#108583 Forward-Port-Of: odoo/enterprise#107974
This update fixes a technical issue where certain Intrastat codes (99450000, 99500000, 99600000 & 99700000) were incorrectly marked as expired. The update 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 an issue where VAT amounts were incorrectly displayed as zero in XML reports generated from manual journal entries. The fix removed a filtering condition that was incorrectly excluding standard journal entry lines from VAT calculations, ensuring accurate VAT reporting for MA Company users.
Original PR description
## Issue: When creating a manual journal entry with a deductible tax, the entry was included in the XML export, but the VAT amounts were all set to 0 ## Cause: The SQL query used to compute VAT amounts included an extra condition on display_type to be 'tax' However, journal entry lines are standard product lines and should not be excluded by this condition As a result, the amounts (MHT, TVA, TTC) were incorrectly computed as 0 in the XML ## Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA Company - Create a Journal Entry (Any account, Debit: 100, Taxes: 10% 150) - Open the Tax Report for the current month - Export the XML using the gear icon Before the fix, the value for mht, tva and ttc where all 0 opw-5226529 Forward-Port-Of: odoo/enterprise#108644
This update fixes a build error in the Odoo Enterprise payroll module related to warning data. The previous test incorrectly counted employees, failing when multiple employees triggered the same warning. The fix now accurately checks for the number of times an employee's ID appears in the warning data, ensuring correct build stability.
Original PR description
> To be FW'ed till `saas~19.1` only. issue: - the test written in commit 0653104 checks the employees' count in warning from `warning_data` dictionary - which will not work in case of multiple employees fulfilling that warning as the warning searches models' data, instead of just test data. fix: - instead of relying on `warning_data['count']` for invalid employee, checked how many times does the invalid employee's ID appear in the `warning_data`. runbot-240910 task-5958862
This update prevents incorrect data from being written to applicant records when OCR processes CVs. Specifically, it stops the OCR email address from overwriting existing business or user contacts, which could have led to inaccurate applicant information. This ensures data integrity within the recruitment process.
Original PR description
When OCR processes a CV, it writes extracted name/email/phone onto the applicant, which then propagates to the linked res.partner via the email_from inverse. This causes data corruption in two cases: - The CV was forwarded: the OCR email belongs to the candidate but email_from is the forwarder's address. Writing OCR data would overwrite the forwarder's partner with the candidate's details. - The existing partner is a company contact (parent_id set) or is linked to a user account (user_ids set). Writing OCR data would overwrite user/business partner with the candidate's details. Both guards are applied and added tests that check the flows. task-5949635
This commit adds the new modules of pos_edi_ubl and l10n_jo_edi_pos to weblate. Forward-Port-Of: odoo/odoo#250549 Forward-Port-Of: odoo/odoo#250324
Original PR description
This commit adds the new modules of pos_edi_ubl and l10n_jo_edi_pos to weblate. Forward-Port-Of: odoo/odoo#250549 Forward-Port-Of: odoo/odoo#250324