Tuesday, November 4, 2025
36 changes · 19.0
New functionality added to Odoo
This change adds a new module to correct and separate Peppol-related tax field handling in invoice export files. It helps Odoo generate UBL documents that better match the official standard, reducing issues with tax allowance charges and related codes.
Original PR description
The new module contains fixes for bugs that were pushed to 19.0 in the `account_peppol_advanced_fields` module. Task: 4963157
Enhancements to existing features
Pakistan payroll tax rules have been updated with the new 2026 bracket values. This helps ensure employee payslips and payroll calculations stay accurate and aligned with the latest local tax requirements.
Original PR description
Tax brackets for pakistan localization has been updated to include the new values for 2026. Forward-Port-Of: odoo/enterprise#98345
Resolved issues and error corrections
When bills are created from QR vendor scans or IRN invoice fetching, Odoo now uses the GST treatment coming from partner autocomplete instead of defaulting to “regular.” This helps ensure the tax setup matches the partner’s actual status and reduces manual corrections.
Original PR description
Before this commit: We used to set `regular` treatment when using QR Vendor Scan or Fetching bill with IRN After this commit: We use the GST Treatment received from Partner Autocomplete to set the GST Treatment task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234136
This update refreshes the QR-code links sent to Avalara when issuing Brazil NFC-e invoices. It helps prevent invoice errors caused by outdated or invalid links, ensuring tax calculations and invoice submission continue to work correctly.
Original PR description
In This PR:
- Several states have updated their NFC-e QR-code URLs, which caused errors when issuing invoices due to invalid or outdated links. This commit updates the 'nfceQrCode' parameter in Avalara requests ('calculate-tax' and 'submit-invoice-goods') to ensure the correct QR-code links are used.
task- 5115845
Forward-Port-Of: odoo/enterprise#95726Messages that include a rating are now treated as non-empty in portal views. This prevents rated feedback from being overlooked and improves the accuracy of customer interactions shown to users.
Original PR description
*: portal, portal_rating, rating, website_slides task-5016995 Forward-Port-Of: odoo/odoo#234059 Forward-Port-Of: odoo/odoo#223515
This update keeps Raspberry Pi and IoT device setup working with newer Python and related system libraries. It also fixes where Wi‑Fi settings are saved, helping ensure network configuration is applied correctly on recent device images.
Original PR description
To ensure compatibility with python 3.13+, we updated the method to generate the rpi's password to avoid using the removed `crypt` lib.
In addition, we ensure that Wi-Fi configuration is saved to the right path, nmcli saving path changed in latest versions. (see: https://github.com/raspberrypi/trixie-feedback/issues/3).
Finally, we ensure compatibility with old `cryptography` versions, by using `not_valid_after_utc` or `not_valid_after` depending on on image version.
Forward-Port-Of: odoo/odoo#234014
Forward-Port-Of: odoo/odoo#233423This update prepares the POS and blackbox integration for a more reliable communication flow by introducing a new action to the connected device. It is the first step toward a queue-based mechanism that will help transactions between the POS and blackbox run more smoothly in the next update.
Original PR description
This commit is the first of two which will introduce a queue mechanism in the communication between the POS and the blackbox. This commit adds an action to the iot and invites users to update their iot to be prepared for the next commit which will effectively add the queue mechanism and use the new action. Second part: https://github.com/odoo/enterprise/pull/90747 Forward-Port-Of: odoo/enterprise#96904 Forward-Port-Of: odoo/enterprise#96639
The Iyzico payment provider now supports webhooks, allowing Odoo to receive payment updates automatically from Iyzico. This improves payment status tracking and makes the integration more reliable for customers and the business.
Original PR description
This commit adds webhook support for the Iyzico payment provider. task-5067754
This update improves how user mentions are detected and validated while composing messages. It also moves part of the message preparation work into a dedicated component, paving the way for a more accurate “what you see is what you get” experience in the composer.
Original PR description
This commit introduces a new MentionPlugin to handle user mentions in the mail composer. The MentionPlugin is responsible for detecting and validating mentions. It listens to selection changes and processes mention elements accordingly. This commit also moves part of the prepareMessageBody logic to the MentionPlugin, so that we can finally get rid of the prepareMessageBody in the future and get what you see is what you get in the composer. task-5137057 backport - https://github.com/odoo/odoo/pull/232538 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Attachment content is now prepared in a way that helps AI find and understand information more accurately. PDFs are indexed more directly, and tabular files are reformatted into a clearer text structure so retrieval results are more relevant.
Original PR description
### Summary
This improvement refines how attachments are indexed to enhance retrieval quality and RAG comprehension.
### Key Changes
- **PDF Indexation:**
- Moved the PDF attachment indexation logic from the previous implementation to the main `_index` method in the `attachment_indexation` module [COM PR].
- PDFs are now indexed directly and their content is stored into `index_content` to be used directly.
- **Tabular File Indexation:**
- In alignment with the community PR that indexes tabular files as CSV text, this update introduces a new helper method:
- `_process_csv_text`: Converts CSV content into a **header–dictionary-style text**, improving semantic understanding for RAG.
---
**Task:** 5045336This update adds extra IGIC tax data for the Canary Islands and splits purchase taxes into goods and services. It helps Odoo apply the correct tax mappings based on the type of purchase, improving compliance and reducing manual adjustments.
Original PR description
We have splitted purchase taxes in goods and services because there are different mappings according to the scope. It has a similar functionality with spanish mainland taxes @jco-odoo There are doubts with the fiscal position `fp_nacional_canary_ns` as it is applied automatically to spanish non canarian partners but it should be similar to non-EU partners IMO. However, I think that the opinion fo some canary people would be nice to clarify it @Christian-RB --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230964 Forward-Port-Of: odoo/odoo#228667
This change greatly speeds up the contract template update process when preparing a new job offer. It reduces unnecessary data processing and database work, which cuts waiting time from minutes to a fraction of a second in large databases.
Original PR description
Description ----------- - Fix performance regressions due to breaking the prefetcher via `[0]` indexing of `hr.version` and batch `write`. - Evaluate only the current employees contracts in `_get_contract_versions` for an *onchange* context, else the `hr. version` for all employees are fetched and evaluated, leading to significant overhead downstream. - Add missing index for `_remove_work_entries` Benchmark --------- On a database in 19.0, with ~10k employees, ~30k versions and ~5M work-entries, the onchange triggered when changing the contract template on a pending offer for a new lambda employee took: | | Before | After | |-------------|--------|--------| | Query Count | 107k | 349 | | Time | 2.9min | ~300ms | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234202
This update corrects how exempt and taxed amounts are placed in Argentina VAT sales CSV files. As a result, taxable operations no longer duplicate values in the exempt column, which helps ensure cleaner reports and successful file uploads.
Original PR description
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the…
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the corresponding handling of exempt and non-exempt balances in the query result processing. These change fixes an issue we encountered when checking the sales CSVs ('Débito' and 'Restitución de débito'). Before this change, the column "Monto Neto Exento o No Gravado" was always filled, even when the operation was not exempt, and in that case it repeated the value of "Monto Neto Gravado".
Here is an example:
<img width="1654" height="187" alt="image" src="https://github.com/user-attachments/assets/578fa197-ab72-4801-b714-9c40ddff4b01" />
The correct behavior should be that for taxed operations, only "Monto Neto Gravado" is filled with the 'balance' value, and for exempt operations only "Monto Neto Exento o No Gravado" should have values.
Here is a screenshot of the 'Debito' CSV after the change:
<img width="1614" height="196" alt="image" src="https://github.com/user-attachments/assets/0a18cbe9-d878-4e37-9bb7-21dc8b5cda72" />
**Summary**
* Changed the column mapping for "Monto Neto Exento o No Gravado" from `balance` to `exempt_balance` in the `columns_map` dictionary in `_vat_simple_build_sale_query`.
* Updated the logic for populating values: added handling for `exempt_balance` and `balance` columns so that only exempt balances are shown in `exempt_balance` and non-exempt balances in `balance`, based on the `is_exempt` flag in the row.
Note: the files created were tested on ARCA environment and they could be uploaded without errors.The label for the company and partner address field used in Saudi e-invoicing has been updated from “Street 2” to “District.” This makes the field’s purpose clearer for users and helps prevent incorrect address entry that could affect invoice compliance.
Original PR description
## Before this commit The `street2` field on `res.company` and `res.partner` was mapped to `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CitySubdivisionName`, but its placeholder displayed `Street 2…`. This caused confusion among users, as they assumed it referred to `cbc:AdditionalStreetName`, leading to incorrect data entry and potential non-compliance. ## After this commit The placeholder of the `street2` field has been changed from `Street 2…` to `District…`, clarifying that this field represents the city subdivision (district or borough) of the Seller/Customer, in line with the Saudi Arabia e-invoicing specification. > Task-4951545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231923 Forward-Port-Of: odoo/odoo#231160
This change prevents a front-end error that could appear when editing a website page while a payment form is present. It makes tooltip cleanup safer so the same element is not processed twice, avoiding interruptions for users working in the website editor.
Original PR description
Following commits odoo/odoo@d37d90891c15b188c2bcb01a51e2ce85cefe287c and odoo/enterprise@901b8eac67324d392ed88997aa9fd1be12dc3752, the tooltip cleanup logic disposes elements in…
Following commits odoo/odoo@d37d90891c15b188c2bcb01a51e2ce85cefe287c and odoo/enterprise@901b8eac67324d392ed88997aa9fd1be12dc3752, the tooltip cleanup logic disposes elements in `website_sale_renting`, and when the same logic runs again
in `payment`, it tries to dispose them a second time, causing
a null element error.
Steps to reproduce:
1. Install `website_sale_renting`
2. Install a demo payment method
3. Go to the shop, add any product to the cart, proceed to payment
4. Click the "Edit" button on the website → observe the error
```js
web.assets_frontend_lazy.min.js:3912 TypeError: Cannot read properties of null (reading 'closest')
at Tooltip.dispose (web.assets_frontend_lazy.min.js:2710:70)
at PaymentForm.<anonymous> (web.assets_frontend_…zy.min.js:8282:1450)
at Colibri.destroyInteraction (web.assets_frontend_lazy.min.js:6472:68)
at Colibri.destroy (web.assets_frontend_lazy.min.js:6524:55)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6584:162)
at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6625:907)
at stop (website.assets_insid…rame.min.js:137:290)
at HTMLDocument.<anonymous> (website.assets_insid…rame.min.js:153:450)
at WebsiteBuilderClientAction.onEditPage (web.assets_web.min.js:22215:55)
```
This fix ensures tooltip cleanup is performed safely without re-disposing already disposed elements.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change fixes a crash that could happen when users group analytic accounts by plan in Accounting. It ensures the totals are calculated safely, so the page loads normally instead of showing an error.
Original PR description
**Steps to reproduce:** 1. Install `accountant` 2. Go to settings and enable `Analytic Accounting` 3. Navigate to Accounting > Configuration > Analytic Accounts 4. Apply Group by plan. **Isuue:** -…
**Steps to reproduce:** 1. Install `accountant` 2. Go to settings and enable `Analytic Accounting` 3. Navigate to Accounting > Configuration > Analytic Accounts 4. Apply Group by plan. **Isuue:** - Traceback `ValueError: Cannot convert account.analytic.account.debit to SQL because it is not stored` **Cause:** - By this commit https://github.com/odoo/odoo/commit/98f746269bdec23e184e9efa83dc30057a458718 a new aggregator function sum_currency was introduced. https://github.com/odoo/odoo/blob/e6928b68bfb2b07e20d9fa49d30a70af0890bd75/addons/web/static/tests/_framework/mock_server/mock_model.js#L1342 in the case of account.analytic.account the non-stored computed fields debit, credit, and balance now receive extra aggregate requests (debit:sum_currency, credit:sum_currency, balance:sum_currency) during web_read_group. **Solution:** - Bypass SQL aggregation for the non-stored fields (debit, credit, balance). Instead of aggregating them in SQL, return the recordsets (id:recordset) for these fields and compute their sums in Python. opw-5101209
This change fixes an error that could show up on the appointment information page when an appointment was limited to work hours and linked to a staff member with flexible hours. The page now handles this case correctly, so customers can view appointment details without running into a 404 error.
Original PR description
This PR fixes the 404 error displayed on the info page of a "Limit to Work Hours" appointment linked to a staff user with flexible hours. The availability of the staff user must not be computed from its work schedules as it has flexible hours. Task-5046134 Forward-Port-Of: odoo/enterprise#95336
This change fixes an issue where upgrades could be processed in a different order from one run to another. By keeping the version list ordered, Odoo now applies migration steps predictably, reducing the risk of inconsistent upgrade behavior.
Original PR description
When we list the versions to upgrade we go over the values in `self.migrations[pkg.name]`. This object is a mapping of mappings `{script_location: {version: scripts_list}}`. The location could be `module` or `module_upgrades` for local scripts, or `upgrade` for scripts in any of the extra upgrade paths.
The problem is that if we have a minor version that matches a major one in different locations the order is non-deterministic. For example if we have a local upgrade script in `1.2`, and an extra upgrade script in `16.0.1.2`. Both `version` keys (`1.2` and `16.0.1.2`) will resolve to `16.0.1.2` when ordering. But the order they _actually_ appear in the set of versions is non-deterministic --due to the `set` implementation in Python.
The solution is to use a container that keeps the order, in this case a `dict`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234124This update improves how Swedish bank account numbers are identified when exporting partner bank details. It ensures several valid account formats are correctly recognized as Swedish, reducing export errors and avoiding manual cleanup.
Original PR description
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the…
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the 'Accounting' page create a new bank account 1- 62074-0 2- 678653833066 3- 99603406872188 - In the partner list view select this new partner - Click Actions > Export, select "Banks" and "Bank Type" - Check the file 1- 62074-0 not recognized as Plusgiro 2- 678653833066 not recognized as BBAN 3- 99603406872188 not recognized as BBAN ### Cause: These numbers are not recognized by the checks of Odoo but are valid numbers: 1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers 2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers 3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969 ### Sources: 1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15 opw-5099867 Forward-Port-Of: odoo/enterprise#98147
The salary simulation for new offers now calculates gross pay correctly even when a contract template has no working hours defined. This prevents the preview from incorrectly showing zero salary and makes offer estimates more reliable for HR users.
Original PR description
Reproduce: In debug mode go to Payroll > Employees > Offers > Create a new offer with a contract template that has no working hours. The gross salary shown in the Salary Simulation Preview is 0. Issue: If the version has no resource calendar, its working hours are 0. This sets the `work_time_rate` to 0, and when multiplied by the wage the gross becomes 0 as well. Fix: Prioritize the version’s resource calendar when available, otherwise fallback to the offer’s calendar, and finally to the company’s. task-5051509
This update fixes the list of work entry types shown when adding multiple work entries from the planning view. It ensures the right options appear depending on whether the user is working in a single company or across multiple companies, preventing missing choices during creation.
Original PR description
Reproduce step: 1. Go to work entries 2. Select some work entries to add using the multiselection in the gantt view. 3. Work entry types doesn't include the ones related to the country. Reason: The country_id is set to False, so the old domain will retrieve only the work entries which are not related to any country. Fix: Add a dynamic domain which depends on the situation, if we are going to create work entries in the gantt views in multi company situation, we will display the work entries types without a specific country only to avoid issues, since it is possible to select employees from different companies at the same time. In the other case (single company) we filter the work entry types based on the self.env.company.id Related task: 5155691. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures the currency and unit shown on emissions are refreshed when the underlying emission factor changes. It prevents outdated values from appearing in ESG reports, improving the accuracy of reporting data.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values. Forward-Port-Of: odoo/enterprise#98724
The Journal Report now keeps the Global Tax Summary in sync when users change the rounding unit. This fixes a mismatch where the main report updated correctly, but the tax summary still showed old formatting and amounts.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98641 Forward-Port-Of: odoo/enterprise#94660
This fix corrects how available stock is calculated when a customer orders both individual units and a package of the same product. Previously, the system could count too much quantity as reserved, causing an item to appear out of stock even when enough was available for pickup.
Original PR description
Steps to reproduce: 1. Add a packaging to the storable product (ex. pack of 6) 2. Uncheck continue selling 3. Update qty of the product in the wh to 20 4. Add 4 units to the cart 5. Add 1 pack 6. Choose pickup in store and go to the checkout The product is not in stock even though there is enough quantity.
This change prevents an error that could occur when users add a project update in projects using budget features. It ensures the update form opens correctly instead of failing during display, improving reliability for project teams.
Original PR description
Currently an issue is generated when the project user tries to add a project update. Steps to produce an error: - Install the 'project_account_budget' module with demo data. - Log in with the demo…
Currently an issue is generated when the project user tries to add a project update.
Steps to produce an error:
- Install the 'project_account_budget' module with demo data.
- Log in with the demo user
- Go to Project and open the dashboard of the Home Construction project
- Click new »> error occurs
Error
```
QWebError
Error while rendering the template:
KeyError: 'revenues'
Template: project.project_update_default_description
```
This issue occurs due to:
- The reference commit [1] enhances the project update form description by enabling the display of profitability even without the sale timesheet.
- With commit [1], code was added to set the `profitability_values` to an `empty dictionary ({})` and `show_profitability` to `False` (see [2]) , since the demo user does not belong to the `project.group_project_manager` group (see [3]).
- In the `project_account_budget` module, the value of `show_profitability` is updated and set to True because the total_budget_amount is present in the project (see [4]).
- In the template `project_update_default_description` rendering, the `profitability` is accessed when `show_profitability` is `True`. However, since `profitability` is an empty dictionary, attempting to access the key will result in an error (see [4]).
This commit fixes the above issue by preventing the recalculation of `show_profitability`, as it is already set based on whether `profitability` data is available or not.
[1]: https://github.com/odoo/odoo/commit/e81af984aabe61defa0932b7890ab373fe3c8e2a
[2]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_update.py#L114-L126
[3]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/models/project_project.py#L1111-L1112
[4]: https://github.com/odoo/odoo/blob/385d8473952eeaa9dcc7740bacfc2c9cbdc2d1e2/addons/project/views/project_update_templates.xml#L26-L31
Sentry-6915109069,6981931420PDF and spreadsheet attachments are now indexed in a way that keeps text and table structure more readable. This improves the quality of search and AI features that rely on attachment content, such as semantic retrieval and RAG.
Original PR description
### Problem 1. **PDF documents** often produced fragmented or misaligned text, especially in multi-column or tightly formatted layouts. 2. **Tabular files** (`.xlsx`, `.ods`) lost their row–column relationships during extraction, making the indexed text less meaningful for semantic processing. ### Changes #### PDF Attachments - Introduced configurable **`LAParams`** parameters in `pdfminer` to fine-tune text extraction for complex or multi-column layouts. #### Tabular Attachments - Updated **XLSX** and **ODS** indexers to output data in **CSV-like format**, preserving **row–column context** for better AI readability. - Uses **`openpyxl`** (now part of Odoo requirements) to efficiently extract and format spreadsheet data in xlsx files. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-id-5045336
This fix ensures the views needed to settle invoices are loaded correctly for users who are allowed to perform the action. As a result, employees without administrator access can now settle invoices as expected, preventing a workflow blockage at the point of payment closing.
Original PR description
Before this commit, a user without the "Role / Administrator" group could not settle invoices because the required views were not loaded. After this commit, the necessary views are properly loaded, allowing all authorized users to settle invoices as expected. opw-5138892
This update keeps the scrap order’s BoM information in sync when the product is changed. It prevents cases where the displayed scrap quantity becomes zero while the actual stock movement still uses the correct amount, avoiding inconsistent results during validation.
Original PR description
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the…
Problem: When a user changes the product on a scrap order, the bom_id field does not get updated. If they update the product from a product that has BoM to a product that doesn’t have one, then the bom_id field is hidden and remains set. This will cause the scrap quantity to be set to 0 when they validate the scrap. However, the product move actually happens for the correct quantity causing an inconsistency. Purpose: This will either set the bom_id field to False if the new product doesn’t have a valid BoM, or it will update it to the first available BoM. Steps to Reproduce on Runbot: 1. Create a scrap order for a product that has a kit type BoM and set the kit field. 2. Change the product to a product without a kit type BoM. 3. Validate the scrap order. 4. Observe the quantity field is set to 0, but there are product moves for the correct quantity. opw-5122880 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234050 Forward-Port-Of: odoo/odoo#231937
The company switcher now correctly displays nested companies a user can access, even when an intermediate company in the hierarchy is not available. This prevents missing entries in the company list and makes it easier for users to switch to the right company context.
Original PR description
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2…
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled. This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list. `companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3. ### Solution: A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies. Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed. opw-4880477 Forward-Port-Of: odoo/odoo#229829 Forward-Port-Of: odoo/odoo#217001
Fixed an issue where checkout could hang indefinitely when external tax calculation failed for Brazilian sales. Instead of freezing, the system now captures the error and continues to show a user-friendly message at the next checkout step, helping customers understand and correct the problem.
Original PR description
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with…
**Issue** When buying products in the Brazilian localization, certain errors in external tax calculation were not properly caught by the frontend. This caused the checkout to hang indefinitely with infinite loading. Examples include missing NCM codes or IAP service failures due to invalid addresses. **Steps to Reproduce** 1. Install Brazilian localizations (l10n_br, l10n_br_avatax, l10n_br_edi). 2. Configure Avatax Transfer API credentials (API ID and Key). 3. Create a website with a Brazilian company. 4. Add a product to the cart and proceed to checkout. 5. Choose a delivery method and observe that the UI gets stuck loading. **Root Cause** The `_order_summary_values` method in `website_sale_external_tax` called `_get_and_set_external_taxes_on_eligible_records()`, which could raise exceptions (e.g., IAPServerError). These exceptions were not handled, so they propagated to the frontend as generic RPC errors. The frontend has no built-in mechanism to display these exceptions as user-friendly messages, resulting in infinite loading. **Fix** Wrap the external tax calculation in `_order_summary_values` and catch `UserError`. Instead of letting the exception propagate as a generic RPC error, attach the error message to the result dictionary under `external_tax_error`. This prevents the frontend from hanging while still making the underlying problem visible in the next checkout step, where validation errors are properly handled and shown to the user. Opw-5052078 Forward-Port-Of: odoo/enterprise#96213 Forward-Port-Of: odoo/enterprise#95045
This change corrects permission handling in attendance settings and overtime calculations. It ensures managers can view the ruleset as intended and that overtime lines correctly identify whether a user is the manager, preventing access issues and incorrect behavior for attendance officers.
Original PR description
Problem ---------- Ruleset can't be read if the user is not an attendance manager. The ruleset_id on employee have the group `group_hr_manager`but it doesn't imply attendance manager. Wrong computation of `is_manager` on overtime line if the user has only attendance officer rights and the employee with overtime has this user as attendance manager. Solution ---------- Make the ruleset readonly for hr manager. Fix the is_manager compute task-5180810
The product catalog now shows the right price when discounts are enabled, even if the product was already added to the order. This fixes a mismatch that could make catalog prices appear inconsistent with the order line and improves accuracy for sales users.
Original PR description
Catalog prices do not consider discounts when displayed separately from the unit price on the order line (if any for a given product). It was fixed for the /update_order_line_info route with 5d1837e47c20f04458472658c4f8ea71284fb6ca, but the issue still remained when fetching the original catalog data on opening, through the /order_lines_info route. This only happened when the product was already added to the order, because in this case we avoid recomputing the pricelist price and use the existing sale order line price. This commit makes sure that the sale order line discount field is correctly considered in that case, and also adds tests to cover the catalog more extensively. Fixes #232219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233098
This fix prevents a permission error when a non-admin user clicks a configurable product in Point of Sale, especially in branch-company setups. The product configurator now opens normally, so staff can continue serving customers without interruption.
Original PR description
**Issue:** In POS, clicking on a tax-free, inventory-tracked, configurable product as a non-admin user can throw an Access Rights error when trying to access it on a branch company's POS config. **Steps to reproduce:** - Configure a branching company on a parent company - Create a new POS restaurant on the child company - Create a configurable product that has no taxes associated with it and add it to a POS category so that it can be chosen from the POS screen - On a non-admin POS user, try to click that product 🐛 **Before this commit:** The user will get an Access Rights error. **After this commit:** The configurator dialog will load successfully. opw-5145176 Forward-Port-Of: odoo/odoo#231343
Self-order preparation printers were missing a needed IoT Box identifier, which could prevent printing through supported connection methods. This update loads the full device information so printing works reliably in self-order, matching the regular point of sale behavior.
Original PR description
Loading IoT preparation printers in self order was not providing the ID of the IoT Box record, required to print using both webrtc/longpolling/websocket. This commit fixes this issue by loading the whole device record, same as we do to load preparation printers in the regular pos.
This fix prevents an error that could appear when manufacturing products tracked by lot and producing more than the requested quantity. It ensures the lot information is kept correctly on the extra output lines, so the production can be completed without a missing lot warning.
Original PR description
For 'By Lots' manufactured products, producing more than requested gives the error "You need to supply a Lot/Serial Number for product...". This occurs from within _post_inventory operations: - update the finished move line with only the producing quantity - create a new finished move line with the exceeding quantity & lot - raise the warning under action_done because one move line has no lot By inverting the updates ( setting the lot before setting the quantity ) we ensure the lot is correctly propagated. task: 5232544 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an error when checking multiple payslips if some of them have no problems to report. As a result, payroll processing is more reliable and won’t stop unexpectedly in these cases.
Original PR description
When there are multiple payslip on which we call get_error_message, some may have no issues. In this case, it raises a traceback as issues is False. Introduced in https://github.com/odoo/enterprise/pull/94748