Tuesday, February 10, 2026
32 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue preventing users with restricted company access from successfully reloading translations. The fix bypasses a privilege check on static data retrieval, allowing the translation reload process to continue smoothly. This improves usability for all users, regardless of their company access permissions.
Original PR description
When a user doesn't have access to all companies, he couldn't reload the translation terms. However, the exception occurs in the call to _get_chart_template_data, which doesn't especially require privileges, because it is static data. With this commit, we bypass the lack of company access to retrieve this data, and let the user continue the language reloading process. Task-id: [5916490](https://www.odoo.com/odoo/project.task/5916490) Forward-Port-Of: odoo/odoo#247602 Forward-Port-Of: odoo/odoo#247540
This update fixes an issue where the quantity displayed in the shopping cart wasn't correctly reflecting changes made during the checkout process. Previously, users would sometimes see an incorrect quantity (1) instead of the updated amount. The fix ensures that the cart accurately displays the quantity selected by the user, improving the shopping experience.
Original PR description
**Steps to produce:** - Install `website_sale` with demo data. - Go to the shop page. - Select product `Customizable Desk` > click `Add to cart`. - In the wizard, change the quantity to 100 and…
**Steps to produce:** - Install `website_sale` with demo data. - Go to the shop page. - Select product `Customizable Desk` > click `Add to cart`. - In the wizard, change the quantity to 100 and directly click `Checkout`. **Issue:** - The cart shows the product with quantity = 1 instead of the edited value. Root cause: - When the user clicks Checkout, both `setQuantity` and `onConfirm` are triggered almost simultaneously. - At [1], the `_setQuantity` method is called, but due to the await before the quantity update is completed, the update may not finish in time. As a result, the previous quantity is sometimes used during checkout instead of the newly selected one. Solution: - we can update the quantity immediately before awaiting `_updateCombination`, ensuring that the correct quantity is already set when onConfirm runs. [1]: https://github.com/odoo/odoo/blob/f4eabe47a602301013afa63da6bdf87809903d29/addons/sale/static/src/js/product_configurator_dialog/product_configurator_dialog.js#L225 opw-5435672 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241424
This update resolves a technical issue preventing the correct Open Graph description from being generated for card campaigns when previewing or sharing them. The fix ensures that campaign suggestions are properly included in the campaign's metadata, improving how campaigns appear on social media platforms. This ensures consistent and accurate campaign previews.
Original PR description
**Current Behavior:** description is not available for the Crowler <img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" />…
**Current Behavior:** description is not available for the Crowler <img width="1159" height="802" alt="image" src="https://github.com/user-attachments/assets/2979f413-6487-4f44-993c-b9a806e0d0ef" /> **Steps to reproduce:** 1. Install `marketing_card` 2. Create a card campaign 3. Set Recipient, Post Link and Post Suggestion 4. Save and Preview 5. Copy the URL and replace `preview` with `redirect` 6. To reproduce in locale, in the `contoller` make the marketing_card.card_campaign_crawler template the only return 7. Now paste that URL in the browser **Issue** - The `<meta property="og:description">` tag is empty in inspect. It does not contain any content **Cause:** - The controller `card_campaign_redirect` passes the campaign's suggestion text to the view using the key `post_text`. However, the template `card_campaign_crawler` attempts to access `post_suggestion`, which is not present in the rendering context. **Solution:** - Update the controller to pass `post_suggestion` opw-5351041 Forward-Port-Of: odoo/odoo#238534
This update resolves a problem where syncing an order with point changes could incorrectly trigger processing for all orders, including draft ones. This change ensures that draft orders are no longer unnecessarily processed, improving order stability and preventing potential errors. This fix was made in response to a reported issue (opw-5370267).
Original PR description
Before this commit, when a draft order with point changes existed, syncing an order would trigger the post processing of all orders, including draft ones. This could lead to issues. opw-5370267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240089
This update resolves an issue where the copy button within Odoo was incorrectly submitting forms. By explicitly setting the button type to 'button', the fix ensures the copy button functions as intended within forms, improving user experience. This change prevents unexpected form submissions.
Original PR description
Previously, the type of the button in the template of the CopyButton utility component was left unspecified. Because the default type for buttons is "submit", the copy button will not work if it is placed within a `<form>` element, and will instead submit the form (see [1]). This commit just forces the type of the button to "button" which has no default behavior, meaning it can be used even inside of `<form>` elements without issues. [1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/button#type Forward-Port-Of: odoo/odoo#247754
This update allows for seamless payment matching between parent and child companies when processing bills. Previously, matching was limited to purchase orders; now, it includes purchase orders within the same company, streamlining financial reconciliation and reducing manual effort.
Original PR description
On bills, the `purchase_vendor_bill_id` field already allows matching with cross-company purchase orders. This commit extends this behavior to payment matching. Steps to reproduce: - Create a child company from a parent company. - Create a purchase order in the child company. - Create a bill in the parent company. - In the bill’s payment matching, the child company’s purchase order should be available. opw-5416947 Forward-Port-Of: odoo/odoo#244973
This update allows Fleet Officers to modify the 'Make Vehicle Available' field, previously restricted to Fleet Managers. This change streamlines the process for officers to manage vehicle availability, improving operational efficiency within the fleet management system. The change ensures officers have the necessary access to update vehicle statuses directly.
Original PR description
Issue: The 'plan_to_change_car' and 'plan_to_change_bike' fields were restricted to Fleet Managers, preventing Fleet Officers from editing it. Fix: Changed the view-level group restriction from Fleet Manager to Fleet Officer for both fields.. task-5443107
This update corrects a pricing issue in the Point of Sale (PoS) system when ordering combo products multiple times. Previously, the system miscalculated the total price, resulting in an incorrect amount. The fix ensures accurate pricing for combo orders, regardless of the quantity of items purchased.
Original PR description
**Steps to reproduce:** - Create a combo, set the free and max to 3 - Create the product combo and set it's price to 50 - Go to PoS, order said combo and chose the same product 3 times - The price is…
**Steps to reproduce:** - Create a combo, set the free and max to 3 - Create the product combo and set it's price to 50 - Go to PoS, order said combo and chose the same product 3 times - The price is 49.98 instead of 50 **Problem:** When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50. **Why the fix:** This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines. In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. The solution would be to take the line's qty into account when computing how much we should subtract. Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend. The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them. As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered. opw-4931215
This update fixes an issue where list markers disappeared when switching between list types (numbered, bullet, checklist) after removing the marker. The change ensures list markers are consistently displayed regardless of the selected list type, improving the user experience when creating and editing lists.
Original PR description
Steps to reproduce: - Create a numbered list - Press Backspace to remove the list marker - Change the list type to bullet or checklist using the powerbox. Current behavior before PR: - The list type is changed to bullet or checklist, but the marker is not visible Cause: - When a list marker is removed using Backspace, the `oe-nested` class is added to the `<li>` element, which hides the marker. - When switching the list to another list type, the `oe-nested` class is not removed. - As a result, even though the list type changes, the marker remains hidden. Solution: - When changing the list type, remove the `oe-nested` class from `<li>` elements that do not contain any list elements as children. - This ensures the marker is correctly restored for the new list type. task-5468384 Forward-Port-Of: odoo/odoo#243001
This update resolves a bug where breadcrumb traceability was missing when opening projects from sale orders linked to multiple projects after migrating from version 16 to 19. The change adjusts the action target to 'current', ensuring proper breadcrumb behavior and aligning with standard Odoo record navigation. This improves the user experience when managing complex projects within sales orders.
Original PR description
Steps to reproduce: 1. Create a db with having 'sale' & 'project' installed in version 16. 2. Create a sale order having linkage to more than single project. 3. Migrate the db to version 19. 4. When…
Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.
Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)
When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17
This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.
OPW-5448916
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#244245This update resolves an issue with the calculation of Mod 390, a key component of Spanish tax reporting within the Odoo system. The changes accurately incorporate balances from specific accounts to ensure correct tax reporting compliance. This fix addresses a technical detail impacting Spanish business operations.
Original PR description
In this commit: Fixing 390 computation: - Add balance from 27, 29, 649 and 31 to casilla 33. - Add balance from 28, 30, 650 and 32 to casilla 34. Related PR : https://github.com/odoo/enterprise/pull/105597 task-5732679 Forward-Port-Of: odoo/odoo#247686 Forward-Port-Of: odoo/odoo#245828
This update ensures consistent styling for mentions across both small and full composer views, improving readability and preventing overflow issues on smaller devices. The change enhances the user experience by aligning the visual presentation of mentions, regardless of the composer size.
Original PR description
Use the same style in full composer than in small composer. Tweak style to account for small device, better handle overflows task-5916878 Before / After (small composer) <img width="342" height="466" alt="image" src="https://github.com/user-attachments/assets/234ff152-3c5a-4c82-b257-2800a752dd3a" /> <img width="496" height="476" alt="image" src="https://github.com/user-attachments/assets/60b3d12d-38ea-429a-9dec-441886ac022e" /> Before / After (full) <img width="413" height="394" alt="image" src="https://github.com/user-attachments/assets/c51e053f-7eb2-4ee0-8a9a-bd068ee9ded0" /> <img width="487" height="555" alt="image" src="https://github.com/user-attachments/assets/d0a3514d-aa1f-4d89-8fe4-7964ec20a288" /> Forward-Port-Of: odoo/odoo#247822 Forward-Port-Of: odoo/odoo#247562
This update resolves an issue where the BoM report wasn't correctly displaying the selected variant. The fix ensures the report consistently uses the variant ID passed from the backend, preventing discrepancies between the report's displayed variant and the user's selection. This improves the user experience when generating BoM reports.
Original PR description
Steps to reproduce on runbot ------------------ Select a product with several variants and a Bill of Materials (e.g. Stool). Change the variants order so that their ids are not ordered, this can be…
Steps to reproduce on runbot ------------------ Select a product with several variants and a Bill of Materials (e.g. Stool). Change the variants order so that their ids are not ordered, this can be done by modifying the default_code for example (e.g. Internal Reference for variant "Color: Green" set to "A"). When accessing the BoM report, you won’t be able to switch to one of the possible variants (in the example the Dark Blue variant). Why it is happening ------------------ The default variant to be displayed when opening the report is selected in the backend using the product_variant_id field. This field is computed as the first element in product_variant_ids as they are ordered in the model. We then send this variant’s information to the frontend and a dictionary containing every variant (key= id and value = display_name). In the serialization process, the object is reordered based on the keys. Thus, if the variants were not ordered based on their ids in python, the order will change. The displayed variant is correct as it has been passed directly but the frontend also computes the currentVariant attribute. This is computed as the first element in the dictionary but in this case, it is not the one that has been selected in the backend, as the order changed. As a result, you see the report for a variant A but the frontend considers you are on the report for variant B so you cannot switch to variant B as you are supposed to be already on it. The fix ------------------ I propose to use the explicitly passed id as the currentVariantId. opw-5409493 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247664 Forward-Port-Of: odoo/odoo#241603
This update corrects and enhances the tax descriptions and names used in the Belgian localization for Odoo. The team has revised all existing translations and added German translations, ensuring accurate and compliant tax reporting. A key change includes fixing the 21% S.INC tax to correctly apply included taxes.
Original PR description
In this commit[^1] the tax descriptions and names for the Belgian localization were added/updated. However, some names or descriptions were either not fully correct, poorly translated, or not translated at all. In this commit, we revised them all and added German translations for everything as well. [^1]: https://github.com/odoo/odoo/commit/c7b39c5ad4afba7e61265773b87f500469ace91b Forward-Port-Of: odoo/odoo#247400 Forward-Port-Of: odoo/odoo#247036
This update corrects a display issue where the phone field was incorrectly marked as required for service products during checkout. Previously, users could confirm their order without filling this field, even though it was indicated as necessary. This change ensures the phone field is correctly shown as optional when a service product is selected, improving the user experience.
Original PR description
### Issue Due to this issue, when the product is service, the phone field is not required, even though there is * marking it as required. #### To reproduce 1- Add a service product to cart 2- Click checkout and fill the address 3- Leave the phone blank 4- Click on confirm As you see, it is allowed to confirm without setting the address while shown as required. ### Cause This is due to https://github.com/odoo/odoo/pull/198731, making phone number not required in quick checkout case. However, this change should also make not required fields to be displayed as optional. opw-5348695
This update fixes an issue where account numbers weren't being properly logged within the account_edi_ubl_cii module. By logging the account numbers directly, the system now captures this critical data more reliably, ensuring accurate financial reporting and compliance. This change improves data integrity and traceability.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247693
This update corrects a previous issue where the user group field in the Odoo interface remained editable even when set to 'readonly'. This fix ensures that the field correctly respects readonly settings, preventing validation errors and improving the user experience. It's a minor UI adjustment that enhances consistency.
Original PR description
Before this commit, the res_user_group_ids field introduced in [1] didn't care about the `readonly` props. As a consequence, when the field (or the whole view, via `edit="0"`) was readonly, the widget still rendered editable SelectMenu. Obviously, editing it and then triggering a save would raise a validation error, so it was only an UI issue. This commit fixes it by properly setting the field in readonly if its props states it. [1] https://github.com/odoo/odoo/pull/179354 task~5922282 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 fixes a previous issue where mention suggestions prioritized recent chat partners over the record's followers. Now, mention suggestions will prioritize the record's followers first, followed by internal users, and then recent chat partners. This ensures users are notified of relevant conversations and updates more effectively.
Original PR description
Before this commit, mention suggestions prioritized partners from recent chats over the record's followers. This commit fixes the behavior by reordering the sequence numbers to have the following priority order: Thread followers > Internal users > Recent chat partners. <img width="1051" height="316" alt="image" src="https://github.com/user-attachments/assets/04b80028-07b5-40b2-8972-e80f933980c7" /> task-5313114 Forward-Port-Of: odoo/odoo#247639 Forward-Port-Of: odoo/odoo#237145
This update fixes an issue where mention suggestions in the full composer weren't correctly prioritizing followers. The fix ensures that suggested users, including followers, are now sorted at the top, improving the user experience and making it easier to connect with relevant contacts. This enhancement streamlines communication within Odoo.
Original PR description
Fetch/sort suggestion in the full composer don't receive the thread param which leads to follower not being sorted at the top. task-5917226 Forward-Port-Of: odoo/odoo#247678 Forward-Port-Of: odoo/odoo#247581
This change resolves a database error during the KSeF integration neutralization process. The issue stemmed from a missing column in the 'res_company' table, which has now been corrected by creating a dedicated column for the 'l10n_pl_edi_session_key' field. This ensures smoother database updates and prevents errors during the neutralization process.
Original PR description
### Issue: Due to recent [commit] (https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.…
### Issue:
Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.
Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n SET l10n_pl_edi_certificate = NULL,\n l10n_pl_edi_access_token = NULL,\n l10n_pl_edi_refresh_token = NULL,\n l10n_pl_edi_session_id = NULL,\n l10n_pl_edi_session_key = NULL,\n l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n ON CONFLICT (key)\n DO UPDATE SET value = 'test',\n write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9: l10n_pl_edi_session_key = NULL,
```
Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
AND column_name LIKE 'l10n_pl_edi%';
column_name
---------------------------
l10n_pl_edi_certificate
l10n_pl_edi_access_token
l10n_pl_edi_refresh_token
l10n_pl_edi_session_id
(4 rows)
```
After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
AND column_name LIKE 'l10n_pl_edi%';
column_name
---------------------------
l10n_pl_edi_certificate
l10n_pl_edi_session_iv
l10n_pl_edi_session_key
l10n_pl_edi_access_token
l10n_pl_edi_refresh_token
l10n_pl_edi_session_id
(6 rows)
```
### Solution:
Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.
Ticket [link](https://www.odoo.com/odoo/project.task/5751411)
opw-5751411
Forward-Port-Of: odoo/odoo#247130This update fixes an issue where accessing messages in Odoo was slow, particularly when browsing records multiple times. The changes optimize how Odoo retrieves message access information, resulting in faster performance and a smoother user experience. This enhancement ensures efficient data retrieval and reduces potential delays for users.
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#247888 Forward-Port-Of: odoo/odoo#245744
This update resolves an issue where reports would display outdated data while waiting for new variants to load. By preventing the display of the initial variant, the system now waits for the complete data to load, resulting in a smoother and more accurate reporting experience. This improves the responsiveness of the account reports.
Original PR description
Previously, when a report was loading if a variant was selected, it would display the first one when it loaded and display the second one when it loaded. With this, we wont show the first one as we are waiting for the new one. To reproduce: - load the Demo data on the demo company - Add time.sleep(5) in _get_lines - load the Generic Tax report and wait for it to load - click on the Group by: Account > Tax and wait for 3s - click on the Group by: Tax > Account - Watch the Account > Tax load and still being displayed for 3s while the Tax > Account variant is loading. Forward-Port-Of: odoo/enterprise#105522
This update enhances the stability of our payroll accounting tests by ensuring all server-side processes are fully completed before tests conclude. This prevents test failures due to incomplete data changes, leading to more reliable test results and faster identification of issues. It's a routine fix to improve the quality of our automated testing.
Original PR description
Wait for signature completion in tours to ensure server-side side-effects are finished before the test ends and asserts the database state. runbot-224112 Forward-Port-Of: odoo/enterprise#106840
This update resolves an issue where accents in legal names were being incorrectly removed, preventing proper recognition by Mexican tax authorities (SAT). The fix restores the correct handling of accented characters, ensuring accurate data submission for Mexican e-invoices. This improves compliance and avoids potential processing delays.
Original PR description
Previus commit (odoo#95207) removed accents for names including character ë which indeed its recognized for SAT opw-5897333 Forward-Port-Of: odoo/enterprise#106557
This update fixes a reporting issue related to withholding taxes for Spanish businesses (l10n_es_reports). Specifically, it ensures that the 'type for 347' field is left blank when processing invoices with withholding taxes, aligning with Spanish tax regulations. This ensures accurate financial reporting.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679 Forward-Port-Of: odoo/enterprise#106796 Forward-Port-Of: odoo/enterprise#105597
This update corrects a bug where the email address for Belgian customers wasn't being included in VAT reports. The fix automatically pulls the email from the customer's contact information, ensuring accurate reporting and compliance. This prevents missing email data in crucial financial documents.
Original PR description
**Steps to reproduce:** - Install l10n_be_reports and contacts - Switch to a Belgian company (e.g. BE Company CoA) - Go to Contacts - Open the company contact (i.e. BE Company CoA) - Add an invoice address withtout email - Create an invoice: * Customer: [a Belgian customer with a VAT number] * Invoice Lines: [a line with a tax] - Confirm the invoice - Go to "Accounting / Reporting / Belgium / Partner VAT Listing" - Export the XML **Issue:** In the XML, "<EmailAddress>" is empty althouth it is mandatory. **Cause:** The email is retrieved from the invoice address, but there is no fallback on the parent contact if it is empty. **Solution:** Fallback on the email of the parent contact as it is the case for the phone. opw-5870750 Forward-Port-Of: odoo/enterprise#106831 Forward-Port-Of: odoo/enterprise#105654
This update fixes an issue where anonymous users booking appointments skipped the address form during payment, leading to incorrect tax calculations. The fix ensures the address form is always displayed, guaranteeing accurate pricing and fiscal position application for all appointment bookings. This improves the overall user experience and financial accuracy.
Original PR description
**Steps to reproduce:** - Install Website/Appointment/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled -…
**Steps to reproduce:** - Install Website/Appointment/Sales apps - Create a new event and set a ticket price - Create a fiscal position (with specific tax) for a country with `auto_apply` enabled - Publish the event - Book an appointment with up-front payment enabled as a anonymous user - The process bypasses the address form and goes directly to payment - The resulting sale order will have no fiscal position - Prices won't be impacted by taxes related to the user billing address **Issue:** Address form is skipped before payment for appointment booking of a public user as `_needs_customer_address` is not overwritten properly in some module. This is probably due to a refactoring that changed how the required information is evaluated in the payment flow (see related commit). **Fix:** Set _needs_customer_address to True by default to avoid such issues in dependant modules. Might need to remove this feature in master as the workarounds are not that clean (geao_ip, check on fiscal position enabled, overwrite everywhere, others ?). related: https://github.com/odoo/odoo/commit/d43f0423667835512e16c3fd3474328da63a948d opw-5143124
This update adjusts the taxonomy used for Dutch tax reports from NT19 to NT20, a standard change required for compliance. The update only involves namespace adjustments and maintains compatibility with older versions of the XBRL template. This ensures continued accurate reporting for our Dutch clients.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359 Forward-Port-Of: odoo/enterprise#106732
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of invoice export processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774
This update resolves an issue where the document search functionality could fail due to incorrect access to contextual data. By switching to a reliable public API, the system now consistently provides the necessary information for accurate document searches, enhancing stability and reliability.
Original PR description
**Before this commit** We were accessing the context on the `DocumentsSearchModel` object by using `_context`. This is incorrect because this property is private, and we can't guarantee its structure. In some cases, `_context` can be `null`, causing later issues when we try to access properties from the context. This was likely just a programming error, rather than intentional. **After this commit** We'll use the public API to get the context by accessing `context` on the `DocumentsSearchModel` object. The internals of that getter method can speak for themselves, but they are useful because they will give us a non-`null` context to work with. opw-5903535 Forward-Port-Of: odoo/enterprise#106751
This update fixes an issue where credit notes were incorrectly displaying negative tax amounts in the tax totals widget. The fix ensures accurate tax calculations and reporting for Brazilian credit notes, improving financial accuracy and reporting reliability. This resolves a discrepancy between calculated tax and its display.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180 Forward-Port-Of: odoo/enterprise#106579
A warning was incorrectly appearing in the Belgian tax report when dealing with carryover lines, suggesting an issue where negative values were being generated. This update removes the misleading warning, ensuring the report accurately reflects the intended calculations for carryover lines. This improves the reliability of the Belgian tax reporting process.
Original PR description
The Belgian tax report was displaying a warning when a negative amount originated from all the lines even from carryover ones. This warning was misleading, as carryover lines are not supposed to generate a declared negative value. task-5411005