Daily updates from Odoo
Thursday, February 26, 2026
60 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where an unnecessary 'add inputs' button was appearing on Swiss payroll payslips. This change ensures a cleaner and more user-friendly experience for users in Switzerland, aligning the payroll interface with Swiss regulations. The fix was triggered by recent updates to the Swiss localization.
Original PR description
don't show add inputs button on payslips on the swiss localization. Forward-Port-Of: odoo/enterprise#107962 Forward-Port-Of: odoo/enterprise#107958
This update fixes an issue where users could add more than the available quantity of a product to their cart when Click & Collect was enabled. The change removes a previous workaround that allowed this behavior, ensuring accurate inventory tracking and preventing over-ordering. This improves the customer experience and prevents stock discrepancies.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Enable click and collect 2. Add a product with tracked inventory 3. Set the quantity on hand 4. Uncheck "Sell when Out-of-stock" 5. Try to add to cart more…
Versions
--------
- 19.0+
Steps
-----
1. Enable click and collect
2. Add a product with tracked inventory
3. Set the quantity on hand
4. Uncheck "Sell when Out-of-stock"
5. Try to add to cart more than the quantity on hand on the product page
- note that you are only allowed to add up to the quantity on hand
6. Try to add to cart more than the quantity on hand from the shop page by hovering over the product and clicking the cart icon
- note that you can add to cart more than the quantity on hand
7. Try to go to the cart page and adjust the quantity of the product
- note that it is reset to the quantity on hand and you're prevented from exceeding it
Issue
-----
You shouldn't be able to add to cart more than the quantity on hand of a product when you have "Sell when Out-of-stock" disabled. Especially since you can't do that from the product or cart page, and adjusting the extra quantity from the cart page leads it to reset.
Cause
-----
When you enable click and collect, it disables the check for quantity when adding items to cart. This was originally done because otherwise you had no way of adding items to cart in case there was a quantity available for pickup from shop but not available for delivery. This has changed since the introduction of the widget on the product page that allows you to select a store to pickup from in that case.
Solution
--------
Remove the code that disables checking for quantity when adding to cart when click to collect is installed.
opw-5449451
Forward-Port-Of: odoo/odoo#249876
Forward-Port-Of: odoo/odoo#242864This update fixes an issue where the documentation index wasn't correctly reflecting the latest changes. Previously, the system was caching outdated documentation, leading to potential inconsistencies. Now, the index is rebuilt dynamically when the 'disable cache' option is enabled, ensuring users always have access to the most current documentation.
Original PR description
Access /doc/index.json with the "disable cache" checkbox from the devtools checked. To index is generated again (emitting warnings in the logs may some docstrings be broken) but it still uses the attachment that was cached by the server. It should not use the server attachment. Reference-to: c67f64d7025c ([FIX] api_doc: respect no-cache directive on index) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249591 Forward-Port-Of: odoo/odoo#249504
This update resolves an issue preventing portal users and internal users from uploading documents to requested documents. The fix addresses a technical error related to how access tokens and folder IDs were being processed, specifically by ensuring that access tokens are correctly handled during the upload process. This improvement ensures all users can successfully upload documents to requests.
Original PR description
Portal users and internal users cannot upload a document in a requested document Steps to reproduce: 1. Install Documents 2. Go to Documents and create a new request for user Joel Willis 3. Connect as portal user and go to Documents 4. Try to upload the requested document 5. An error occurs The same problem occurs for user Marc Demo Problem: Sending both an access_token and a user_folder_id to the controller raises an error 400 https://github.com/odoo/enterprise/blob/519862bf9b708d756478d4d81787f8a1999bc574/documents/controllers/documents.py#L608-L609 Solution: Do not send a user_folder_id when we have an access_token opw-5439104 Forward-Port-Of: odoo/enterprise#106583
This update resolves a technical error that prevented users from submitting UK tax reports when the company's VAT value was left blank. The fix ensures that VAT is always set on the company record, allowing successful connection and report transmission to HMRC. This resolves a blocking issue impacting UK tax reporting.
Original PR description
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5 - Install l10n_uk_reports module - Keep the VAT value empty for the UK Company - On the Tax…
Steps to Reproduce: https://www.awesomescreenshot.com/video/49329263?key=2daddfb65e4ee8dcf1a047c09c6bd2b5
- Install l10n_uk_reports module
- Keep the VAT value empty for the UK Company
- On the Tax Report (GB), click Connect to HMRC
- Establish connection with HMRC
- After a successful connection, try to send the tax report to HMRC
- Traceback will appear
<details><summary>Exact Traceback</summary>
<p>
```
RPC_ERROR
Odoo Server Error
Occured on 100710704-master-all.runbot216.odoo.com on model account.report on 2026-02-11 12:50:03 GMT
Traceback (most recent call last):
File "/data/build/odoo/odoo/http/requestlib.py", line 632, in _serve_db
return retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/retrying.py", line 52, in retrying
result = func()
^^^^^^
File "/data/build/odoo/odoo/http/requestlib.py", line 687, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/dispatcher.py", line 308, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/addons/base/models/ir_http.py", line 374, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/http/routing_map.py", line 207, 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 57, in call_kw
result = method(recs, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2825, in dispatch_report_action
return report_to_call.dispatch_report_action(options, action, action_param=action_param, on_sections_source=False)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/account_reports/models/account_report.py", line 2836, in dispatch_report_action
return report_method(model, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/account_financial_report.py", line 30, in send_hmrc
self.env['l10n_uk.vat.obligation'].import_vat_obligations(self.env.context['client_data'])
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 124, in import_vat_obligations
self._get_vat(),
^^^^^^^^^^^^^^^
File "/data/build/enterprise/l10n_uk_reports/models/hmrc_vat_obligation.py", line 111, in _get_vat
if vat.startswith(('GB', 'XI')):
^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'startswith'
The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3225:165)
at XMLHttpRequest.<anonymous> (https://100710704-master-all.runbot216.odoo.com/web/assets/0a37914/web.assets_web.min.js:3231:13)
```
</p>
</details>
Reason:
- No VAT set on the current company.
Solution:
- Blocking level error for the user to set VAT on the current company.
Task-5929908
Forward-Port-Of: odoo/enterprise#107150This update resolves an issue where the website builder's sidebar incorrectly switched to a 'block' tab when using the translate mode, triggered by hiding and showing sections. The fix ensures the 'customize' tab remains active, providing a smoother and more consistent experience for users managing website translations.
Original PR description
With commit 3a80ac79c5b0193911e8ddab442660b315562639, the builder option plugin is not a custom one in translate. And the builder option plugin automatically switches to a fallback tab (instead of customize tab) when containers are de-activated. This happens when the user hides an invisible element. This commit fixes it by skipping swithing to fallback tab if the builder is in translation mode. Steps to reproduce: - Open website builder - Drop a section - Make it invisible on desktop - Add a language to the website - Open builder in translate mode - Click on the eye of invisible elements to show the invisible section - Click again to hide it - Bug: the sidebar left the "customize" tab and switched to "block" tab task-5475107 Forward-Port-Of: odoo/odoo#242618
This update resolves a technical issue that could cause Odoo Enterprise to crash when Avatax company credentials are unavailable. The fix prevents a crash by handling the situation gracefully within the Avatax integration process, ensuring stability and continued functionality.
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 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 resolves an issue where invoices generated with the Folder layout in India (l10n_in) were being duplicated in the PDF print output. The problem stemmed from a formatting element in the invoice header that caused pagination errors. The fix adjusted the header tag to prevent this duplication, ensuring accurate invoice printing.
Original PR description
**Steps to reproduce:** 1. Install l10n_in module 2. Switch to india 3. Go to Settings → Configure Document Layout and select Folder layout. 4. Create two Invoices: Select a customer. Add at least 6–7 invoice lines. Confirm the invoices then duplicate and again confirm. 5. Go back to the Invoice list view. 6. Select both newly created invoices. 7. Click Print **Issue:** When using Folder layout, invoices were rendered twice in PDF while printing. **Cause:** The `HSN Summary` title used an `<h3>` tag. Its larger default margins increased the document height, triggering a pagination reflow issue in wkhtmltopdf specific to Folder layout (due to floats and dynamic header spacing). This caused the invoice to be rendered twice. **Fix:** Replaced `<h3>` with `<h4>` to reduce vertical spacing and avoid pagination overflow. opw-5452609 Forward-Port-Of: odoo/odoo#249413
This update resolves a bug where the booking management page wouldn't refresh correctly. The fix ensures the page renders properly after a refresh, improving the user experience for managing appointments within the POS system. This prevents disruptions and ensures accurate booking data.
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
A recent update to Odoo's mailing builder caused a crash when using company team snippets. This fix corrects a renaming issue where an image component was incorrectly labeled, preventing the builder from functioning properly. The update ensures the builder operates smoothly with company team templates.
Original PR description
The `Img` component was renamed `Image` in commit [1]. In the forward port [2], a template with usage of `Img` was not updated to use `Image` instead, resulting in an issue when using the company teams snippet. How to reproduce: - create a new mailing using the builder - add the s_company_team_shapes snippet - click on an `<img>` element Issue: - crash (Img component is missing) Solution: - rename Img to Image [1]: https://github.com/odoo/odoo/commit/a22e22acacc9d54f39d0f07acc3054cd2a33f61e [2]: https://github.com/odoo/odoo/commit/d2b56435736e8d507434c1378cb68fae23e8511f task-5963711 Forward-Port-Of: odoo/odoo#250234
This update fixes an issue where Gantt progress bars displayed incorrect hours due to timezone discrepancies. The change ensures that working hours are accurately calculated and displayed, regardless of the employee's calendar timezone, leading to more reliable planning data.
Original PR description
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee…
### Issue: Having a calendar with a timezone different from utc and looking at the planning gantt view, the hours displayed in the "Total" row are wrong. ### Steps to reproduce: - Have an employee with a calendar in "Europe/Brussels" and working from 8 to 17 - In planning add a line for this employee - Display the gantt view on a day - Create a shift for this employee from 8 to 17 - In the "Total" row, the first hour is not counted ### Cause: To compute the values displayed in the Total row, we take the intersection of the shift and the working hours from the calendar. ([src](https://github.com/odoo/enterprise/blob/2b887d094c66be7aebd92fbf735b1852f5dde4b5/planning/static/src/views/planning_gantt/planning_gantt_renderer.js#L318)) But the working hours from the calendar are given in UTC for this computation (without conversion), this result in a discrepancy between the actual hours of the calendar (with timezone conversion) and the one given to compute the total row. ### Solution: `resource_work_intervals()` returns the work intervals with the calendar hours and the resource timezone. In our case, only the hours are interesting (the previous code replaced the timezone by UTC). We need to convert them from the calendar timezone to UTC. So the first thing to do is remove the timezone from `resource_work_interval` then we localize it in the calendar timezone and to finish we convert it to UTC. opw-5564749 Forward-Port-Of: odoo/enterprise#108369 Forward-Port-Of: odoo/enterprise#106891
This update corrects a formatting issue in the Eco Voucher export file, ensuring it aligns with the specific requirements of the Monizze system. This resolves a potential compatibility problem that could have prevented accurate data transfer for tax reporting. The change ensures seamless integration with our financial reporting partner.
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
This update resolves an error that previously prevented users from opening the Tax Returns report. The fix ensures that the report can successfully generate the necessary tax information by preventing errors related to invalid data IDs. This improves the reliability of a key accounting function.
Original PR description
Currently, an error occurs when a user opens the Tax Returns report. **Steps to Reproduce:** - Install the `Accounting` module. - Go to `Journal Entries` and create a journal entry with lines, `Ex:`…
Currently, an error occurs when a user opens the Tax Returns report. **Steps to Reproduce:** - Install the `Accounting` module. - Go to `Journal Entries` and create a journal entry with lines, `Ex:` - One `Receivable` line with a positive debit. - One `Income` line with the same credit. - `Post` the journal entry. - Go to `Accounting > Closing > Tax Returns`. - Set the `date` and click `Apply`. `AssertionError: Invalid falsy real id` When opening the Tax Returns report, it going generates the Annual Closing Checklist. During this process, it tries to get the unknown partner’s account line ID [1]. However, if the line_id does not contain anything related to the target model (account.move.line), the method returns None [2]. Later, it attempts to browse using this None value which raise the error [3]. This commit ensures that only valid ids are added, preventing None values from being browsed. [1]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2365-L2371 [2]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_report.py#L2461 [3]: https://github.com/odoo/enterprise/blob/887fb85cf3ed488187418c03df159af859a4e435/account_reports/models/account_return.py#L2399 sentry-7263718845 Forward-Port-Of: odoo/enterprise#107524
This update corrects a problem where payment reference data from a specific data source (Codabox) was incorrectly formatted, often with extra spaces. The change automatically removes these spaces before processing, ensuring accurate record creation and preventing potential data errors. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update resolves an issue where the location selector would unexpectedly gain focus when no location was initially selected. This improvement ensures a smoother and more intuitive user experience for users managing deliveries within Odoo.
Original PR description
Forward-Port-Of: odoo/odoo#250680
This update fixes a previous issue where searching for archived accounts didn't display their associated journal entries. Now, users can view all journal items, regardless of whether an account is archived, providing a more complete financial overview. This improves reporting accuracy and simplifies account management.
Original PR description
This commit makes it possible to see the journal items for archived account when searching for the account. Previously, when searching for an account that is archived, its journal items weren't shown. task-5905559 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250420 Forward-Port-Of: odoo/odoo#249422
This update resolves a technical issue that caused a 'Singleton Error' when users configured multiple 'Buy' or 'Manufacture' routes for their products. The fix ensures that only one default route is selected, preventing errors during the replenishment process. This improves product availability and stability.
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 corrects a display issue where the tooltip icon in the HTML Builder wasn't correctly mirrored for right-to-left languages (RTL). The fix ensures that the icon appears correctly regardless of the user's language setting, improving the builder's usability for international users. This resolves a previous bug introduced during a recent update.
Original PR description
Among other things, commit [0aba7f3] added a `?` icon on builder options with a tooltip. However: - since [94e17fd], the key `state.tooltip` was removed from the BuilderRow component (to use `props.tooltip` directly), but the XML wasn't properly adapted in 19.0. - the icon isn't mirrored in RTL languages. This commit fixes both issues. [0aba7f3]: https://github.com/odoo/odoo/commit/0aba7f383c86dec00e9fc6d324a5bfdec7a19707 [94e17fd]: https://github.com/odoo/odoo/commit/94e17fd9845486a959f2544e1b26199abc96a56a task-5109547 Forward-Port-Of: odoo/odoo#250232 Forward-Port-Of: odoo/odoo#244024
This update fixes an issue where the FAIA report incorrectly classified partners as suppliers instead of customers, particularly when credit notes were involved. The change allows a partner to be recognized as both a customer and supplier, ensuring accurate reporting of balances and improving the reliability of the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#108197 Forward-Port-Of: odoo/enterprise#100749
This update corrects a minor oversight in the invoice matching process within the Odoo Enterprise accounting module. The tolerance setting for matching invoices was unintentionally left unchanged after a previous update, leading to potential inaccuracies. This fix ensures accurate reconciliation of bank statements and invoices.
Original PR description
During this commit:https://github.com/odoo/enterprise/commit/15d26e62f14bb0224712a1712b47ebe16c3b8702 we forgot to change one part of the hardcoded tolerance. task-5952881 Forward-Port-Of: odoo/enterprise#108377 Forward-Port-Of: odoo/enterprise#108112
This update corrects a bug where loyalty points were incorrectly calculated and duplicated after saving a POS order, particularly in draft and cancelled states. The fix ensures that loyalty points are accurately reflected based on the order's state, preventing over-accumulation of points. This improves the accuracy of customer loyalty programs.
Original PR description
Step to reproduce: - have a trusted pos and a loyalty program which gives points per $ spent - start pos and select order and a partner (he should already have some LPs) - notice the loyalty points…
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248420
Forward-Port-Of: odoo/odoo#245400This update resolves an issue where duplicate receipts were appearing on point of sale tickets. The problem stemmed from a system error triggered by a specific user interaction, leading to unnecessary receipt confirmations. This fix 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 update resolves a validation error occurring during tax calculations for invoices in Brazil (BR) localization. The issue stemmed from the system incorrectly considering existing tax data, leading to inaccurate information sent to the AvatTax service. This fix ensures correct tax calculations are sent to AvatTax, preventing invoice validation failures.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not…
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735 Forward-Port-Of: odoo/enterprise#108403 Forward-Port-Of: odoo/enterprise#108088
This change addresses a technical issue where a syntax error during UI view rendering could cause a crash. The fix ensures that a 'None' value is assigned before an error occurs, preventing the 'UnboundLocalError'. This improves the stability of the user interface.
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 fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to uncertain data, which has now been addressed by simply removing the problematic information. This ensures smooth and reliable processing of incoming payments.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
This update resolves an issue where certain Intrastat codes (99450000, 99500000, 99600000 & 99700000) were incorrectly marked as expired. The fix ensures these codes remain active, aligning with official Belgian regulations outlined in the Intrastat manual, preventing potential reporting discrepancies.
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 the Swiss ISO20022 payment XML generation was producing invalid files due to incorrect data formatting. Specifically, it ensures that only one of BIC or ClrSysMmbId is included, aligning with Swiss banking standards. This prevents payment processing errors and ensures compliance.
Original PR description
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor…
**Steps to reproduce:** - Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company - Have a bank with a BIC number and an account for that bank with a clearing number - Create a vendor bill for a Swiss partner or payrun report - Pay with "Swiss ISO20022" > generate xml pain001 - Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml ! **Cause:** In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf). **Solution:** Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6). opw-4872507 Forward-Port-Of: odoo/enterprise#108461
This update resolves an issue where users could trigger a type error when creating custom domain filters in the sale order list. The fix ensures that the system correctly handles cases where a field name is missing, preventing the error and allowing users to create filters as intended. This improves the usability of the sales order filtering feature.
Original PR description
Currently, an error occurs when user tries to validate a domain with no field name. Steps to install: - Install `sale_management` > Open sale order list view > Turn on debug mode. - Click on search…
Currently, an error occurs when user tries to validate a domain with no field name.
Steps to install:
- Install `sale_management` > Open sale order list view > Turn on debug mode.
- Click on search bar > Custom filter > Click on field and remove its field name written below the list of fields.
- Click validate.
Error:
```
TypeError: Empty field name in condition ('', '=', 1)
```
Cause:
- As the field name was emptied by the user the [line] will raise a TypeError during the domain validation.
- Till `19.0` any error during domain validation was handled through [here] which was later changed to handle only ValueErrors through this [commit].
Solution:
- Handled TypeErrors during domain validation.
[line]: https://github.com/odoo/odoo/blob/260b9c0417ed2278429fcdd7f50d61786d4e9beb/odoo/orm/domains.py#L841
[here]: https://github.com/odoo/odoo/blob/a220fb71c036c93fa1e75d4d37127e5eda0118f9/addons/web/controllers/domain.py#L34
[commit]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b#diff-e5da86414a8020b2843fb359453238e4977027d30f73f1fa792ca63ddd8fa2a7L34-R23
sentry-7278978488
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#249993This update fixes an issue where VAT calculations were incorrectly set to zero in XML exports for manual journal entries. The fix removed an unnecessary filter in the SQL query, ensuring accurate VAT amounts (MHT, TVA, TTC) are now correctly calculated and exported. This ensures accurate reporting for tax compliance.
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 bug in the Point of Sale (POS) system where a product with a unique serial number would cause an error when the ‘Lot/Serial number(s) required’ dialog was discarded. The fix prevents further actions from being taken after discarding this dialog, ensuring a smoother POS experience for users.
Original PR description
Steps to reproduce: = - Configure a product with `Tracking`=`By Unique Serial Number` - Open POS and click on the configured product. - The “Lot/Serial number(s) required” dialog opens. - Click `Discard`. Issue: = - The following error occurs: `TypeError: Cannot read properties of undefined (reading 'modifiedPackLotLines')` Fix: = - Stop further steps to add the product when the lot/serial number dialog is discarded. Reference: = - https://github.com/odoo/odoo/pull/238635/files#diff-9e8905c1e88dc96f9145acda2c6a165fb14a58e0d2cfb5b3b6049411918ba27dL913-L914 task-5505855 related pr: https://github.com/odoo/enterprise/pull/108263 Forward-Port-Of: odoo/odoo#245165
This update resolves an issue where products with unique serial numbers in Odoo's Point of Sale (POS) system were causing traceability problems. The update ensures that order line configurations are correctly applied when a product's serial number is involved, improving order accuracy and reporting. This fix was part of a larger effort to enhance POS functionality.
Original PR description
In this commit: = - Overridden `requiresOrderLineConfiguration` so that `configureNewOrderLine` is also called when lot or scale configuration is required. task-5505855 related pr: https://github.com/odoo/odoo/pull/245165 Forward-Port-Of: odoo/enterprise#108263
This update fixes an issue in the barcode picking interface where users were repeatedly prompted to confirm adding multiple extra products. Now, the confirmation dialog opens only once and allows users to easily select or deselect products before final validation, streamlining the picking process.
Original PR description
When adding extra products in the barcode picking interface, the confirmation dialog did not handle correctly the scan of multiple extra items. Before: Scanning multiple extra products successively opened (mutex + promise) the dialog multiple times. The user had to confirm/cancel each extra product addition one by one. After: The dialog is now only opened once and updated when scanning multiple extra products before confirming. The user can select/deselect the extra products to add before validating. [opw-5193269](https://www.odoo.com/odoo/project/49/tasks/5193269) Forward-Port-Of: odoo/enterprise#108623 Forward-Port-Of: odoo/enterprise#104932
This update fixes an issue where loyalty discounts weren't accurately calculated when products had taxes included in their price. Previously, discounts were incorrectly applied to the base price instead of the discounted price. This ensures loyalty rewards are applied correctly, providing accurate discounts to customers.
Original PR description
When applyin a discount by percentage on the cheapest product if the product was using a tax included price, the discount was wrongly calculated on the tax excluded price. Steps to reproduce: ------------------- * Create a tax of 15% included in price * Create a product with a price of 10€ and assign the tax created before * Create a loyalty program with a reward of 100% discount on the cheapest product * In POS, add the product to the order > Observation: The discount applied is of 8.7€ instead of 10€ Why the fix: ------------ We make a similar fix to this one : https://github.com/odoo/odoo/pull/240289 opw-5260067 Forward-Port-Of: odoo/odoo#249584 Forward-Port-Of: odoo/odoo#244734
This update fixes an issue where Odoo incorrectly displayed records after a user switched between companies. Previously, the system didn't immediately update the URL needed for correct record loading, leading to incorrect views. Now, the system reliably directs users to the correct record after a company change, ensuring a smoother user experience.
Original PR description
Have a flow where an action act_window is executed and wants to open a record in the form view, but that record is not in one of the companies that the current user is logged in. The ORM will crash with an access denied, that the JS catches cleverly (see odoo/odoo@6213c40932236101b529b82f0ea9fce1829c8c24) and tries to reload on that failed action after altering the allowed companies. Before this commit, this flow was imperfect because the url (that allows to reload at the right place) was not written immediately. So, more often than not, we ended up on the wrong view after reload. After this commit, we end up in the right action after reload. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250401
This update fixes a bug that caused time off requests to be incorrectly displayed as allocations within the reporting system. The issue stemmed from a misalignment in the database queries used to generate the reporting views. This change ensures that time off requests are accurately displayed and routed to the correct reporting pages, improving the user experience for requesting and tracking time off.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249015
This update ensures that pickings are automatically created when validating POS orders linked to sale orders. Previously, stock levels weren't updated correctly if pickings were scheduled for the end of a POS session. This fix guarantees accurate stock tracking and order fulfillment for POS transactions.
Original PR description
Before this commit, when validating a POS order linked to a sale order, if the Inventory Management was configured to create pickings at the end of the session, no picking was created for the order, and the sale order stock was not updated. This commit fixes this issue by ensuring that the picking is created for the imported sale orders in real time. opw-5423113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248424 Forward-Port-Of: odoo/odoo#244739
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 activities.
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. 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 fixes an issue where preparation tickets weren't printed correctly when using the self-ordering kiosk mode. The fix prevents a system update from overwriting key data, ensuring preparation tickets are generated reliably during kiosk transactions. This improves the overall kiosk ordering experience.
Original PR description
Steps: --- - Configure a preparation printer and enable it for kiosk mode. - Open a kiosk session. - Place an order and complete it. Issue: --- - Preparation tickets were not printed in kiosk mode. Cause: --- - In kiosk flow, preparation changes are sent on conformation page. - After sync, `LOPC` was overwritten, preventing preparation data from being processed. Fix: --- - Do not update `LOPC` when self-ordering mode is kiosk. - Refactor and re-enable preparation ticket checks in unit tests. task-5973158 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves intermittent test failures related to image loading on the website. By proactively fetching and caching images, the test suite now completes much faster – reducing the time from 26.7 seconds to 15.4 seconds. This improves the stability and reliability of our website tests.
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 bug that prevented the inclusion of specific fields (Ask Restitution and Client Nihil) in the Belgian VAT return PDF reports. The change re-enabled a key mechanism for customizing reports, ensuring accurate and complete VAT return documentation. This resolves an issue reported by users generating these reports.
Original PR description
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper. 18.3-:…
This commit https://github.com/odoo/enterprise/commit/e8d2084369d58717c2294e023cbdfd60f713c334 removed the `pdf_options_header` wrapper.
18.3-:
https://github.com/odoo/enterprise/blob/ce67bf6fb4f694c25785580fe3ed290bcb8c92b5/account_reports/data/pdf_export_templates.xml#L151-L154
18.4+:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/account_reports/data/pdf_export_templates.xml#L159-L160
This broke `l10n_be_reports` which uses `(//div[hasclass('row')])[last()]` to inject BE-specific fields:
https://github.com/odoo/enterprise/blob/e3746aba3c334a628a15a4263ddfa08876d2a288/l10n_be_reports/data/tax_report.xml#L9-L24
Without the wrapper, `[last()]` targets the conditional `aml_ir_filters` row instead, making BE fields invisible.
Steps to reproduce:
1. Create a Belgian company
2. Navigate to Accounting → Reporting → Tax Return
3. Create a VAT Return and submit it
4. Check the generated PDF in the attachment
=> The "Ask Restitution" and "Client Nihil" fields are missing from the PDF header.
Ticket [link](https://www.odoo.com/odoo/action-4043/5509725)
opw-5509725
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#107519This update corrects a technical issue where the 'is_company' field wasn't accurately determined in Odoo's localization modules for Brazil and Ecuador. Specifically, it now correctly identifies companies based on their identification type (CNPJ and RUC) and, for other countries, flags a partner as a company if a VAT number is provided. This ensures accurate reporting and compliance.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/odoo/pull/211043 Task-5947797 Forward-Port-Of: odoo/odoo#249037
This update corrects a bug in Odoo's localization modules (l10n_br and l10n_ec) that incorrectly identified companies. Now, the system accurately determines if a partner is a company based on their identification type (CNPJ or RUC) in Brazil and Ecuador. For other countries, a partner is considered a company if a VAT is provided.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797 Forward-Port-Of: odoo/enterprise#107674
This update corrects a bug in the website's image carousel that prevented correct navigation in right-to-left languages like Arabic. By adding a specific HTML attribute, the carousel now correctly displays the next and previous images when using the arrow keys, ensuring a consistent user experience regardless of the website's language setting.
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#250668 Forward-Port-Of: odoo/odoo#240611
This update fixes an issue where the payroll update process would fail when a common working schedule was deleted. The fix ensures that payroll data continues to update correctly, even after a schedule is removed, preventing data inconsistencies. This impacts all supported countries.
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#108730
Forward-Port-Of: odoo/enterprise#106950This update fixes an issue where kits with multiple components were incorrectly showing a zero cost when using FIFO or average costing methods. Now, the system accurately calculates the total cost of a kit, ensuring accurate inventory and sales reporting. This improves the reliability of our point-of-sale and manufacturing processes.
Original PR description
Before this commit, if a kit had multiple components, the cost of the line was counted as zero if the product cost method was FIFO or average. opw-5911338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247833
A small typo in the code processing messages from Mercado Pago was causing errors and preventing successful payments. This update corrects the typo, ensuring Mercado Pago payments are now processed correctly. This resolves a technical issue impacting payment functionality.
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 Forward-Port-Of: odoo/odoo#250818
This update resolves a visual issue in the Discuss app where a horizontal scrollbar would appear on smaller screens. The fix adjusts how the app's layout adapts to different window sizes, ensuring a consistent and usable experience for all users. This improves the app's responsiveness and usability.
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 contract signing requests would fail with error messages due to a missing link between the contract and an employee offer. The fix checks if an offer exists before attempting to update the contract, ensuring proper signature validation and preventing redirect errors. This improves the user experience for employees and administrators.
Original PR description
Steps to reproduce: 1- On an employee page, create a new signature request for a document through the gear icon 2- Log in with the employee (ex. Marc Demo) and sign the contract 3- It will be signed but you will still get an <error 404 not found> page as it redirects to an offer that does not exist 4- Log in with the admin again to counter sign the document 5- You will get an error saying contract end date cannot be before contract start date Cause of the bug: We don't have an offer linked to the document we're signing. We can test this with the demo employee_contract.pdf or Employee Termination.pdf. The logic inside the sign() function will try to update the employee's version with fields from the offer which we don't have as it assumes this is a new offer. Fix done: Check if we have an offer linked to this sign request at first, if not return the default behavior that validates the signature. task-5423393 Forward-Port-Of: odoo/enterprise#102934
This update corrects a discrepancy in payslip calculations for employees using the private car daily allowance. The daily amount is now rounded to two decimal places, ensuring the displayed value aligns with the total amount calculated by multiplying quantity and rate on payslips. This improves the accuracy and transparency of payroll reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108498 Forward-Port-Of: odoo/enterprise#106753
This update resolves an issue where gift card payments on Ecuadorian POS orders were incorrectly flagged as requiring an SRI payment method. The fix automatically applies the SRI payment (code '01') when a POS order has no associated payments, ensuring accurate invoicing and compliance. This prevents errors and improves the user experience for customers using gift cards.
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
A recent change was causing the 'Publish & Send' button to disappear in the scheduling interface. This fix removes a temporary workaround and directly addresses the root cause by removing the unnecessary condition affecting button visibility. This ensures the 'Publish & Send' button remains visible when scheduling.
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 delivery slips incorrectly calculated package weight by omitting the weight of products inside. The change ensures that the total shipping weight accurately reflects the weight of the outermost package and its contents, improving shipping accuracy and cost calculations. This impacts all users who rely on delivery weight information.
Original PR description
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type…
On delivery slip, the total weight of a package doesn't include the weight of the product in the outermost package. Steps to reproduce: ------------------- * Create a Package "Pa" with a package type that has a weight * Create a product "Po" tracked by quantity * Add two units of the product Po to the package Pa * Create Delivery with two units of Po. * Confirm the Delivery and print the delivery slip -> The total weight is the weight of the package type without including the products inside. Observation: ------------- When computing the shipping_weight for the delivery, it will fallback on the package_weight to calculate it weight, https://github.com/odoo/odoo/blob/ca14f1aa21a75398919c1453be19011522bb3b5c/addons/stock/models/stock_picking.py#L893-L906 It retrieve the weight calculated by _get_weight https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock/models/stock_package.py#L435 Except for the outermost package, where it incorrectly considers only the package type weight and does not include the products weight opw-5499770 Forward-Port-Of: odoo/odoo#250358 Forward-Port-Of: odoo/odoo#247227
This update fixes an issue where the website builder's sidebar wasn't properly blocked during reloadable actions, particularly under slow network conditions. Now, the sidebar remains blocked while templates are updated, ensuring a smoother and more reliable user experience for website customization. This enhancement improves the overall usability of the website builder.
Original PR description
When we perform a reloadable action in the builder, the builder's UI is not blocked, unlike in previous versions before the html_builder [refactoring] Steps to reproduce the issue: - Open website, and click on the header - In the dev tools, set the network throttling to 3G or slow 4G - Change the header's template => Notice that the sidebar is not blocked, while it should be. [refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5952793 Forward-Port-Of: odoo/odoo#250753 Forward-Port-Of: odoo/odoo#249526
This update resolves a technical issue preventing the account reports annotation tour from functioning correctly. The change adjusts the confirmation button used in the tour to align with recent styling updates, ensuring the tour now triggers as intended. This improves the user experience for accessing and utilizing account reports.
Original PR description
This PR updates the account reports annotation tour to use the correct confirmation button after the dialog styling change, fixing the failing test trigger. community: https://github.com/odoo/odoo/pull/247708 task-5873845
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, particularly when dealing with small inventory quantities, 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 introduces a new ‘Net Cost’ salary rule in the UAE payroll system. Previously, rules deducting from employee pay incorrectly reduced employer costs. This change ensures accurate tracking of employer contributions by separating employee deductions from employer costs, improving financial reporting.
Original PR description
## Before: - Setting appears_on_employee_cost_dashboard to True on a salary rule uses the rule’s sign to compute employee cost. - For rules like Social Insurance Employee Contribution and DEWS Employee Contribution, the sign must be negative to deduct the amount from the employee, which incorrectly reduces the employer cost as well. ## After: - Introduced a new salary rule “Net Cost” to correctly reflect employer cost. - This allows employee contribution rules to keep a negative sign for deductions while still increasing the employer contribution amount. Task-5912761
This update streamlines the process of adding and locating bank accounts within Odoo Enterprise. The changes consolidate how bank accounts are handled across multiple modules, leading to a more consistent and reliable experience for users. This enhancement improves data accuracy and simplifies bank integration for financial transactions.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update fixes a problem that was preventing accurate payslip calculations for employees with specific salary rules. The issue stemmed from how the system handled temporary input fields, leading to an error. This change ensures payslips are computed correctly regardless of how input fields are initially added or hidden.
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#108731 Forward-Port-Of: odoo/enterprise#107326