Daily updates from Odoo
Wednesday, April 8, 2026
44 changes · saas-19.1
Enhancements to existing features
This update improves how Odoo handles Thai VAT (Value Added Tax) information. It now correctly identifies companies based on the leading digit of a Tax Identification Number (TIN), ensuring accurate accounting and reporting for Thai businesses. This change ensures compliance with Thai tax regulations.
Original PR description
In this commit: - For Thailand, TIN is distinguishable between an individual and a company by a prefix. - TIN starting with '0' means the contact is a registered corporate entity, such as a company or partnership. If TIN begins with any digit from 1-9, it indicates that the contact should be treated as an Individual. task-6002111
This update adds a reference field to journal entries generated from stock movements, making it easier to track the origin of transactions. Previously, identifying the source document was difficult, requiring manual review of individual lines. This enhancement improves audit trails and compliance.
Original PR description
To make auditing easier, this commit ensures that journal entries generated from stock movements include the source document reference. Currently, the 'ref' field on these account moves is often empty, forcing users to inspect individual lines to identify the origin. - updates `_create_account_move` in `stock_move`. - collects unique references from the stock moves using `mapped`. - populates the `account.move` 'ref' field with a comma-separated list of these references. task-5499000 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#254889
This update upgrades the software running on our IoT boxes to version 19.2. This ensures the boxes receive the latest features and improvements, and will automatically update to the next version in two weeks after this change is implemented. This update is specific to the IoT boxes currently using the 19.1 version.
Original PR description
This PR updates the current version of the iot boxes to saas-19.2. This only applies to the iot boxes currently in saas-19.1 This will lead to the iot boxes updating to the next version 2 weeks after this PR is merged task-5949470
Resolved issues and error corrections
This update adjusts the VAT number used in the 'L10nThaiTaxReportTest' test case to align with recent changes in how companies and individuals are created within Odoo. This ensures accurate reporting for Thai tax purposes and maintains consistency with updated business processes.
Original PR description
in this commit:- - We're changing partner's vat in 'L10nThaiTaxReportTest' and adopting new vat as per new way of creating company and individual. as `branch name` is depend upon 'is_company'. - see https://github.com/odoo/odoo/commit/f6e431c813787958897526a4d6570124048b428a task-6002111
This update fixes an issue where the helpdesk website displayed all published knowledge articles, regardless of which team the helpdesk was associated with. Now, the website only shows articles linked to the specific helpdesk team or its related teams, improving the user experience and ensuring relevant information is presented.
Original PR description
To reproduce: ============= - create multiple published knowledge articles - link one of them to a helpdesk team - check the help page on website -> all public articles are listed Problem: ======== when fetching the articles to list, we don't take into account the team configuration and we list all the published articles. Solution: ========= fetch only the article linked to the team or its children. opw-5913355 Forward-Port-Of: odoo/enterprise#113025 Forward-Port-Of: odoo/enterprise#109361
This update resolves a technical issue preventing the accurate registration of super payments in the Australian payroll system. The fix initializes an error message to avoid returning NULL values, ensuring data integrity. New tests have been added to verify the corrected functionality.
Original PR description
. Initialize the error message with an empty string to avoid returning NULL. . Add corresponding tests task-6091444 Forward-Port-Of: odoo/enterprise#112930
This update resolves a crash in the Gantt view that occurred when opening the view on days with Daylight Saving Time transitions. The fix addresses an issue where incorrect time calculations led to a data error, preventing users from accessing the Gantt chart. This ensures the Gantt view remains stable across different time zones.
Original PR description
Steps to reproduce 1. Set your timezone to Asia/Beirut 2. Open a Gantt view (e.g. Planning) in week scale on the last Sunday of March (DST spring-forward day) Issue Beirut's DST spring-forward makes that day only 23 hours long. luxon's .diff() works in absolute time, so diffColumn() returned a float (e.g. 6.958 instead of 7 for a full week). Array(6.958) throws RangeError: Invalid array length, crashing the entire gantt view. Forward-Port-Of: odoo/enterprise#112840
This update resolves a technical issue in the UrbanPiper Test Order wizard where clicking an 'open product' icon caused a system error. The fix disables the product form opening functionality within this specific wizard, preventing the error and improving stability. This ensures the test order process functions correctly.
Original PR description
Steps to Reproduce ---------- - Make an UrbanPiper Test Order - Select a product - Click the external-link (open) icon - POS traceback appears Issue ----------- Clicking the “open product” icon triggered a traceback because the POS attempted to load the missing hr_expense_product_form view. Fix -------------- Disable form open/create for the product field to remove the quick-open product icon, as there is no need to open the product form from this wizard. Task-6089707
This update fixes an issue related to how dates and times are displayed in the Enterprise version of Odoo. The system now correctly shows seconds when requested, and previously hidden formatting options have been removed for clarity. This ensures consistent and accurate time representation across the application.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo/odoo@062b140 opw-6030342 Forward-Port-Of: odoo/enterprise#112505
This update resolves an issue where manufacturing orders weren't correctly incorporating component variants during intercompany purchases. The fix ensures that the correct variant information is retrieved from the purchase order, allowing for accurate production scheduling and fulfilling intercompany transactions properly. This improves the reliability of intercompany order fulfillment.
Original PR description
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost. Steps to reproduce: ------------------- * Enable intercompany transaction * Enable variant…
In a multicompany setting, when buying product with intercompany rule, the never variant attribute was lost.
Steps to reproduce:
-------------------
* Enable intercompany transaction
* Enable variant grid entry
* Enable multistep routes
* Unarchive MTO
* Settings>Users & Companies>Companies
* Enable Generate Sales Orders in company A
* Create a product:
- Never variant with at least two values
- MTO and manufacture
* Create a bom,
- Company : company B
- Add a component with apply on variant: choose one of the variants
* Create and confirm a purchase order, for a never variant of the product, in company A with vendor as company B
* Confirm the sales order in company B
-> The manufacture order does not include the components that are applied on variant
Observation:
-------------
When creating a sale order for an intercompany rule, button_approve is overwritten and it calls the function "inter_company_create_sale_order.
That function will create the sale order from the data of the purchase order:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
When preparing the value for each order line, the attribute value for the never variant will not be retrieved:
https://github.com/odoo/enterprise/blob/273528ba462f2f2b5768bf29dbdb697713a8e619/sale_purchase_inter_company_rules/models/purchase_order.py#L63-L64
Since the attribute value is lost, it will not be retrived by the mto since it should get the value from the PO.
opw-5438723
Forward-Port-Of: odoo/enterprise#107122This update fixes an issue where users couldn't validate delivery orders when using the 'To Pickup' button in the industry_fsm_stock module. The fix removes a technical restriction that prevented the form view from opening, now enabling users to properly complete the delivery order process.
Original PR description
Steps to reproduce: - Install `industry_fsm_stock` - Create a task and add a product - Click on the "Sale Order" button - Add another product with the Invoicing Policy set to "Delivered quantities" - Click on the "To Pickup" button Issue: Users are unable to validate the delivery order from the products pick up button. Cause: In pr https://github.com/odoo/odoo/pull/227630 the parent view is set with `editable="bottom"`, which prevents opening the form view from the list. Fix: Allow opening the form view from the list view so users can validate the delivery order. Task-5969303 Forward-Port-Of: odoo/enterprise#110125
This update resolves a display issue in the Danish balance sheet and profit & loss reports. The changes simplify the report format by using account names directly, and ensure accurate Danish translations for both the report and its English counterpart. This improves the clarity and usability of financial reports for Danish users.
Original PR description
We updated the Danish balance sheet and profit and loss reports to reflect the changes in the Danish chart of accounts and common practice in Danish accounting. We also simplified the reports to use the accounts themselves as sublines instead of having a separate report line for each account. Finally we made sure we use the official Danish translations and updated the English translations as well. task-5929517 Related: https://github.com/odoo/odoo/pull/256541 Forward-Port-Of: odoo/enterprise#113097 Forward-Port-Of: odoo/enterprise#112430
This update fixes an issue where rental order confirmations didn't properly update the shift status in Planning. Now, shifts are automatically marked as 'published' when a rental order is created, ensuring accurate status tracking. Additionally, access to certain buttons has been restricted for users without sales permissions to prevent access errors.
Original PR description
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in…
sale_renting_planning: fix shift state after creating rental order -------- **Steps to Reproduce:** Create a shift in Planning. Click New Order. Save and confirm the rental order. Check the shift in Planning it is still in draft. **Issue:** The shift stays in draft even after the rental order is confirmed. **Cause** When creating a rental order from a shift, the shift is not marked as planned. It only gets linked to the order after saving, so it never updates its status. **Fix:** Mark the shift as published when confirming a new rental order. This makes the shift show the correct status right away and keeps it consistent with the “Add to Last Order” button. sale_renting_planning: fix access error on clicking new order button ---------------- steps to reproduce: user has no sale access (only planning access) create a new shift click on 'New Order' or 'ADD to Last Order' button access error occurs cause: the 'New Order' and 'Add to Last Order' buttons were visible to users without sales access rights. issue: The buttons open the sale order form view, but users without sales access cannot read sale orders data, resulting in access errors. fix: Hide both buttons for users who do not have sale access rights. task-5075839 Forward-Port-Of: odoo/enterprise#112373 Forward-Port-Of: odoo/enterprise#99642
This update corrects a test within the Odoo Enterprise web_studio module to reflect a recent change in the user interface label for a text formatting option. Specifically, the test now correctly identifies the new label 'Select text style' instead of the previous 'Select font style'. This ensures the test accurately validates the functionality after the label update.
Original PR description
#### Description of the change: - Update the expected test string from "Select font style" to "Select text style" after the label change. community-https://github.com/odoo/odoo/pull/236904 task-5155813
This update resolves an issue where the breadcrumb navigation within the Barcode app was sometimes showing a blank entry instead of the originating document's name. Now, when navigating from Barcode actions to related records, the breadcrumb correctly displays the document name, improving user clarity and ease of navigation. This ensures users can quickly understand the context of their work.
Original PR description
*: stock_barcode_mrp, stock_barcode_picking_batch ## Issue Before This PR: When navigating from the Barcode client action (e.g. picking, inventory, etc.) to related form views (such as lot, product,…
*: stock_barcode_mrp, stock_barcode_picking_batch
## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.
## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
- Delivery Orders.
- Manufacturing Orders
- Batch Pickings
- Inventory Count
- From any of these open a record
(e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.
## Cause of the Issue:
- When switching views inside the Barcode client action,
the FormController calls `setDisplayName(this.displayName())`.
In some cases, this returns an empty string, overwriting the
previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
preventing the controller from retrieving a proper name.
## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.
TaskID: 4978997
Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165This update fixes a layout issue in the Italian Libro Giornale PDF report. When accounts with long names are used, the report's formatting was broken, causing excessive column expansion and gaps. The fix adds a CSS class to handle long account names, resulting in a cleaner and more readable report.
Original PR description
When generating the Libro Giornale (IT) PDF report with an account that has a very long name, the column expands excessively and break the layout. Steps to reproduce: - With an IT company setup - Have an account with a very long name - Create an invoice using the account - Open Accounting / Reporting / Audit Reports / Journal Audit - Select variant "Libro Giornale (IT)" - Print PDF Issue: The long account name makes the column excessively large. As a result, the font shrinks to fit the page width, leaving wide gaps between lines. **before patch** <img width="794" height="493" alt="screenshot_047" src="https://github.com/user-attachments/assets/6faa5b57-9c60-41cb-9200-003a50019180" /> **after patch** <img width="793" height="553" alt="screenshot_046" src="https://github.com/user-attachments/assets/e97c8948-410b-4201-83c3-04173220d9ce" /> opw-5457103 Forward-Port-Of: odoo/enterprise#112743
This update resolves an issue preventing the correct generation of Intrastat reports when using French language settings that utilize commas as decimal separators. The fix also addresses a previous error related to product weights, ensuring smoother report processing. This improvement enhances the reliability of Intrastat reporting for French-speaking users.
Original PR description
Before this commit, in 19.0+, languages that use commas instead of periods for decimals could not download the intrastat report. Simply attempting to change a string to a float was not enough. Also, when a product had a NoneType weight assigned to it another trace back would occur. This also adds a more descriptive and helpful error message. opw-6026730 Forward-Port-Of: odoo/enterprise#112627
This update fixes how default customer partners are assigned when creating orders in our Point of Sale (POS) system for specific countries (Chile, Colombia, Ecuador, and Guatemala). The change centralizes partner assignment, ensuring consistent and accurate order creation across these localized versions. This improves order processing reliability and data accuracy.
Original PR description
Replace the `createNewOrder()` override with `getDefaultPartnerId()` in l10n_cl_edi_pos, l10n_co_edi_pos, l10n_ec_edi_pos and l10n_gt_edi_pos. The default partner assignment is now handled centrally in `point_of_sale`'s `createNewOrder()`. opw-6077656 Forward-Port-Of: odoo/enterprise#112467
This update adds a required empty field to Milestone actions within Odoo. This change ensures the system's database remains stable during upgrades by adhering to a technical constraint that prevents conflicting action definitions. It’s a routine maintenance update to maintain data integrity.
Original PR description
Add an empty `python_method` field to the Milestones embedded actions. This is necessary to satisfy the `_check_only_one_action_defined` constraint during database upgrades. The `ir.embedded.actions` model enforces an XOR constraint between `action_id` and `python_method`, preventing both fields from being set simultaneously. Related PR: https://github.com/odoo/odoo/pull/254102 task-5993183 Forward-Port-Of: odoo/odoo#254106
This update fixes an issue where the animation intensity slider disappeared after switching animation modes on the website. The problem stemmed from a code change that consistently added a styling class, preventing the slider from reappearing until the same effect was selected again. This ensures a consistent and expected user experience when customizing website animations.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Click any text in the footer. 3. Change the animation mode from _none_ to _on appearance._ 4. Select the _zoom out_ effect; the intensity slider is visible. 5. Change the animation mode to _on scroll_. Issue: The animation intensity slider is no longer visible. It only reappears after reselecting the same effect. Reason: The `apply` method of `SetAnimationModeAction` always adds the "**o_anim_fade_in**" class, even when an animation effect is already selected. When switching the animation mode, this additional class prevents the intensity slider from being displayed. task-5896549 Forward-Port-Of: odoo/odoo#246921
A minor bug that caused a traceback when deleting a toggle list item has been resolved. The fix prevents an error when there isn't a subsequent item in the toggle list, ensuring the delete function works correctly. This improves the stability and reliability of the To-Do module.
Original PR description
Steps to Reproduce: - Go to To-Do → Create New - Create a toggle list - Type something in the title - Press the delete button Description of the issue: - A traceback occurs. Cause: - In `handleDeleteForwardTitleEnd`, there is a check to verify whether the toggle title’s next sibling matches the toggle selector. However, when there is no next sibling, calling `matches()` results in a traceback. Solution: - Only check `matches()` if the next sibling exists. task-6040479 Forward-Port-Of: odoo/odoo#257157 Forward-Port-Of: odoo/odoo#254557
This update fixes a misleading error message users saw when trying to add property fields to records without a parent (like categories). The message has been replaced with a clearer instruction: "A <parentFieldLabel> is needed to add property fields." This ensures users understand the requirement and can easily correct the issue.
Original PR description
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent…
Issue: ------------------------------------------ - When using property fields (e.g., products since 18.1 where categories are optional), users trying to add a property field without a parent document receive a generic warning: "You need edit access on the parent document to update these property fields". - This message is misleading and does not explain the actual dependency. How to reproduce: ------------------------------------------ 1. Create or edit a record (e.g., product) without setting its parent (e.g., category). 2. Try to add a property field. Cause of the issue: ------------------------------------------ - In `checkDefinitionWriteAccess`, when `definitionRecordId` is missing, the method returns `false`, triggering a generic access-rights warning. Solution: ------------------------------------------ - Added a check at the beginning of `onPropertyCreate` verify if `definitionRecordId` exists. - If missing, following error is raised using the parent field label: "You must set the '%s' field to create a property field." task-4589393 Forward-Port-Of: odoo/odoo#257875 Forward-Port-Of: odoo/odoo#205107
This update resolves an issue with the Windows IoT installer by correcting file paths and adjusting logging levels. The change ensures the installer functions correctly and provides more detailed information for troubleshooting, improving stability and reliability.
Original PR description
this commit fixes incorrect paths for the Windows IoT installer and updates log levels to INFO instead of WARNING.
This update corrects a visual issue where the display name within avatars appeared extremely narrow. The fix adjusts the width of the avatar component, ensuring names are displayed correctly and consistently. This improves the overall user experience and presentation of user profiles.
Original PR description
This commit fix the width of the displayName option of the Avatar component which was fixed to zero (bootstrap class 'w-0') Task-5122979 Forward-Port-Of: odoo/odoo#257869 Forward-Port-Of: odoo/odoo#257587
This update resolves an issue where the search panel displayed an error message ('Too many items to display') when dealing with large datasets. By adding a filter to limit the number of records shown, the search panel now correctly displays data without the error, improving the user experience. This ensures a smoother and more reliable search experience, especially with extensive data.
Original PR description
Have a search view with searchpanel having a filter or a category with a limit. For exemple in sale.order:
```
<searchpanel>
<field name="partner_id" icon="fa-filter" groupby="parent_id" limit="80" enable_counters="True"/>
</searchpanel>
```
On a database with a lot of data, in the category partner of search panel, there is an error 'Too many items to display.'.
Now in the search view, add a filter to restrict the number of records, and hence the number of partners in the search panel below the limit.
Before this commit, the error was still displayed. Now, it isn't, and the data are properly displayed.
Closes #257749
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#257908
Forward-Port-Of: odoo/odoo#257821This update fixes an issue where kiosk orders were automatically replaced with generic names like 'Table tracker X'. Now, customers can consistently use the custom order name they initially entered, ensuring accurate order tracking and a better customer experience. This change improves order clarity and reduces potential errors.
Original PR description
Before this commit, when a customer placed an order from a kiosk and provided a custom name, it was systematically overwritten by the backend with a generic "Table tracker X" or the tracking number. task-id: 6014281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue with how dates and times were displayed, specifically regarding the inclusion of seconds. The change restores the original behavior of showing seconds when requested, and clarifies documentation to avoid confusion. This ensures consistent and accurate time formatting across Odoo.
Original PR description
In this [commit] the short format has been removed from misc methods because there was no more _short format fields in res.lang. But the short format was used to remove seconds from the res.lang format. Now, this behaviour has been restored with the new datetime format system and the unused format 'long' and 'full' has been removed from the doc string to avoid misunderstanding. The formatDateTime from the JS use the format from the res.lang too. So the same behaviour has been implemented there to be able to show seconds through the option 'showSeconds'. It's also fix the fact that this option didn't have any effect when the datetime was shown in numeric mode. [commit]: odoo@062b140#diff-61162ac65633a1c7b054fc83ce1813f1a7984e3169ff36021713ef441f62a208 opw-6030342 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255004
This update ensures that stock landed costs accurately reflect the currency rate used when the invoice was created, regardless of subsequent currency rate changes. Previously, the system used the current date's rate, leading to incorrect cost calculations. This fix updates the calculation to use the invoice's currency rate, improving financial accuracy.
Original PR description
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and…
**Issue**: Even if the currency rate is changed on the invoice, the today currency rate is used while generating stock landed cost. **Steps to reproduce**: - Enable two currencies (ex: Dollar and Euro) - Enable Landed Costs on the settings - Create a service product - Create a bill for that product for 100 dollar and click the Landed Costs check box - Change the currency rating (ex: 1 USD = 0.5 euro) and confirm the bill - Click on "Create Landed Costs" -> The cost is not 200 **Cause**: While creating the landed cost: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L21 it uses `_convert` from the currency: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/stock_landed_costs/models/account_move.py#L35 which gets the `conversion_rate` defined on the currency, regardless whether `is_invoicing` is true: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/odoo/addons/base/models/res_currency.py#L294 https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move.py#L6350-L6351 **Solution** It is safe to replace the `convert` calls by the `currency_rate` of the `Account.move.line` since: https://github.com/odoo/odoo/blob/e906eb23d698061f146ba67aae420eb7bb5e8a68/addons/account/models/account_move_line.py#L735-L747 `currency_rate` will be set as `_get_conversion_rate` when not invoicing. Also add rounding since `_convert` is called with `round=True` by default. opw-6047031 Forward-Port-Of: odoo/odoo#256394
This update resolves an issue where invoice generation would fail if a line item didn't have a tax assigned. The fix adds a check to prevent the system from attempting to calculate tax values when none are present, ensuring invoices are generated correctly even for invoices without taxes.
Original PR description
Issue: Attempting to generate facturae document for an invoice without a tax set on one or more line resulted in an IndexError. Solution: adding a check that prevents the function from trying to build tax values when there is no tax on the line. 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#256819
This update resolves a visual glitch that appeared when formatting tables in the To-Do module. Specifically, applying formatting like bold would create unexpected blank lines above the table. The fix prevents styling of system nodes, ensuring proper layout and a consistent user experience.
Original PR description
Steps to Reproduce - Go to To-Do - Add a table - Type content inside the table - Select all using Ctrl + A - Apply formatting (e.g., Bold) Description of the issue: An empty line appears above the table and the layout shifts unexpectedly after applying formatting. Cause: `data-selection-placeholder` nodes exist before and after the table. These nodes normally have zero height. When selecting all content, these placeholder nodes are also included in the selection. Applying formatting styles them as well, which changes their height from zero. As a result, they become visible and appear as newly added blank lines, even though no new line was actually inserted. Solution Exclude system nodes, such as selection placeholder elements, from formatting operations. This prevents them from being styled and avoids unintended layout shifts. task-5976361 Forward-Port-Of: odoo/odoo#252416
This update resolves an issue where the 'Export XML' button for EU Standard (Peppol Bis 3.0) invoices wasn't functioning correctly. Now, users can download invoices in the required XML format when selecting this eInvoice type, ensuring compliance with Peppol regulations. This improves the process of exchanging invoices with partners in countries like Croatia.
Original PR description
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice…
Issue: Export XML button doesn't produce the same file as the send button. Steps to reproduce: - Company in Spain with Peppol (work with any Peppol country) - Partner in Croatia - Select eInvoice Type as "EU Standard (Peppol Bis 3.0)" - Create an invoice - Confirm it - Click on the Wheel -> Download Current behavior: - without l10n_hr_edi: only "PDF" and "PDF without Payment" - with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file Cause: "Export XML" button appear only if: - there is a default ubl option for the partner country - there is an XML attached to the invoice when clicked it exports the corresponding one. Whereas, the 'send' button rely on: 1) the partner defined edi format, 2) the default ubl option for the partner country 3) "ubl_bis3" To be noted: The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice. opw-5943500 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253650
This update ensures the Danish localization for Odoo accurately reflects the latest tax regulations from Denmark. It updates account details, translations, and migration scripts to maintain compliance and provide accurate financial reporting for Danish businesses.
Original PR description
We updated the following in the Danish localization: - Updated the accounts to match the latest version provided by the Danish tax authorities. - Made sure we use the official Danish translations for the accounts and updated all of the English reference translations. - Removed outdated accounts and tags and have a migration script archive them for existing users. - Updated the account groups to match the CoA structure and use the correct Danish and proper English translations. - Adapted the account tags to match the updated accounts/numbers and replaced the outdated ones with their new version on existing accounts. - Removed unused account tags. - Updated some of the default accounts and prefixes on the chart template. task-5929517 Related: https://github.com/odoo/enterprise/pull/112430 Forward-Port-Of: odoo/odoo#257786 Forward-Port-Of: odoo/odoo#256541
This update corrects a previous issue where Point of Sale order reports incorrectly displayed margin values in the wrong currency. The fix ensures that all margin calculations, including the overall order margin, are accurately converted to the company's base currency, providing more reliable reporting for financial analysis. This improves the accuracy of sales data and helps with better business decision-making.
Original PR description
When making a pos order in a PoS that uses a different currency, the margin in the pos order report would not take the currency into account Steps to reproduce: ------------------- * Create a product with a price of 100€ and cost 0€ (margin = 100€) * Setup a PoS to use a different currency with a rate of 2 (so 1€=>0.5) * Create a PoS order for this product and validate it * Go to the pos order report and select the order you just made > Observation: The value of the margin is 200 expressed in the different currency, when the rest of the report is using the company currency. Why the fix: ------------ The currency was only applied on the product cost, we now apply it on the whole margin. opw-5927473 Forward-Port-Of: odoo/odoo#257642 Forward-Port-Of: odoo/odoo#255344
This update addresses a technical issue within the web editor by preventing direct modifications to its history. Removing this functionality also resolves a previous error related to data copying, ensuring stability. This change improves the reliability of the web editor.
Original PR description
This commit prevent direct write to history, also, removes it from copy_data as it would fail anyway when trying to write the history Forward-Port-Of: odoo/odoo#220239 Forward-Port-Of: odoo/odoo#217167
This update fixes an issue preventing portal users from saving changes to their profile information. The change adjusts how access rights are handled, ensuring a `sudo` is only used when explicitly needed. This improves the user experience for managing their portal profiles.
Original PR description
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses >…
# How to reproduce - Install the eLearning module - Log in as a portal user - Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course) - Go to Courses > View your profile (on the right side) > Edit Profile - Edit any value and confirm by clicking on the Update button # The problem The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records" # Why In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe : https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615 This was the case because we preventively filtered only the safe fields in the save controller : https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153 In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled : https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884 One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed. # Proposed solution We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo` opw-6032339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a minor issue by allowing users to remove certain account move lines that have been created with incomplete or inaccurate information. Previously, these lines remained in the system, potentially causing confusion. This change streamlines the accounting process by removing unnecessary and outdated entries.
Original PR description
-added some conditions to allow the user to remove some zero move lines as they may have been created and do not have good information. task-4590580 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#257148 Forward-Port-Of: odoo/odoo#202272
This update resolves an issue where kit products were being incorrectly rounded during purchase order valuation, leading to inaccurate cost distribution. The fix ensures that kit product costs are accurately split across components, preventing rounding errors and maintaining accurate financial reporting. This improves the reliability of kit product costing.
Original PR description
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### >…
### Steps to reproduce: - Create a kit product with 6 bom lines (with a `cost_share` of `0.0%`) - Create + confirm a purchase order for 1 unit of the kit product at 60 - Validate the delivery #### > 6 layers were created with values 9.99, 10, 10, 10, 10 and 10 There are two issues with purchased kit valuation addressed in this PR: ### Issue 1: Since 8c199f7783527735b35c9fbda334cbdcd55a004f, the product price unit is not supposed to be rounded anymore. However, kit products rely on the rounded `cost_share` field of the `mrp.bom.line` to determine which part of the price of the kit product is handled by which component: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/mrp/models/stock_move.py#L245-L246 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L28 https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/stock_move.py#L38 This leads to inevitable rounding issues where `60/6` does not match `10`: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/tests/test_purchase_mrp_flow.py#L1273-L1275 simply because 1/6 is represented as `16.67%` and not by `16.66666666666666%`. However, values such as 1/6 can be obtained if you do not set any `cost_share`, since the kit explosion will equidistribute its cost share: https://github.com/odoo/odoo/blob/591102ff37fef1f0b9a946fee3f9d85789653e65/addons/purchase_mrp/models/mrp_bom.py#L42-L48 ### Fix of this issue: We set the digits to `False` for stability reason as the columns have been initiallised as "numeric" values and needs to stay numeric: https://github.com/odoo/odoo/blob/b007b0a4f7e56f6dc44df3154e13745c9981eae3/odoo/fields.py#L1627-L1650 Note that when the digit is Falsy on the field, the field value is formatted to the second digit by the front end: https://github.com/odoo/odoo/blob/3542c542eac5b204e69a8dd6ae1907cfcef60af3/addons/web/static/src/views/fields/float/float_field.js#L58-L76 https://github.com/odoo/odoo/blob/12e453302a950df4d9ee45954f54bdf610888eda/addons/web/static/src/core/utils/numbers.js#L214-L227 In particular, when we create the bom and set the `cost_share`, all possible values will be rounded to the second decimal just as before. This change will therefore only alter the rounding behavior in the DB for equidistributed values such as `16.66666666666666%`. ### Issue 2: While the value of the kit product is exploded and distributed among components, the values of each individual `stock.valuation.layer` are themselves rounded before creation based on the company currency: https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/product.py#L240-L255 https://github.com/odoo/odoo/blob/4188436a9e800b062bf9f3b0055cad86acc47e19/addons/stock_account/models/stock_valuation_layer.py#L30 Now, this is problematic since the sum of the values of the layers is expected to match the total value of the purchase order line (that is, the non-rounded value of the components of the purchased kit). ### Fix of this issue: We compute and distribute the rounding error among layers corresponding to the purchased kit product before creation (since layer values are not expected to be modified afterwards), based on the non-rounded computation, since this value should now be exact (as the unit cost is not rounded anymore). opw-5085457 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253734 Forward-Port-Of: odoo/odoo#252034
This update corrects an issue where the toolbar in the HTML editor wasn't appearing correctly when selecting individual columns within a table. The fix ensures the toolbar accurately aligns with the selected cell, improving the user experience and allowing for precise editing. This resolves a visual inconsistency and enhances usability.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a 3 x 3 table. - Select 3rd column and wait for toolbar. Currently, the toolbar is positioned at the start of the table even when the last column is selected. This happens because selecting cells in the 3rd column creates a DOM selection range that starts at the first cell and ends at the last cell of the column, traversing all intermediate elements. As a result, browser's range rectangle does not match the actual custom-selection rect. **Desired behavior after PR is merged:** Now, Toolbar is positioned correctly above the custom selected cells. task-5935587 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257879 Forward-Port-Of: odoo/odoo#248964
This update fixes a minor performance issue in the website's breadcrumb visibility preview feature. Previously, the system unnecessarily saved configuration changes even when simply viewing the preview. This change ensures that updates are only saved when a user actively makes a modification, resulting in a smoother user experience.
Original PR description
The option for the visibility option of the breadcrumbs uses a custom save handler (the same as for the header and the footer). To avoid making the rpc to save the options when nothing has been changed, it keeps a flag telling whether there has been any change. This flag was set when changing the visibility option for the breadcrumb even when simply previewing the option. This commit uses the same strategy as for the header and footer's option, and only set the flag if not previewing. task-5149984
This update allows users to disable automatic PDF generation when importing XML invoices. Previously, Odoo automatically created PDFs for these invoices, even if a PDF wasn't included in the XML. This change provides greater flexibility and control over invoice processing, aligning with user preferences and reducing unnecessary file creation.
Original PR description
Commit 7bc35c4 introduced automatic PDF generation for imported XML invoices that don't include an embedded PDF file. However, this behavior was mandatory and couldn't be disabled. This commit adds a new configuration parameter to allow users disable this behaviour. Task-6050566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257604 Forward-Port-Of: odoo/odoo#254847
This update fixes an issue where caching proxies were incorrectly storing the 'load menus' response, potentially leading to all users seeing the same menu structure. The change ensures that intermediaries like caching proxies don't store this data, improving menu performance and consistency across our user base. This was necessary after a previous change removed the 'unique' parameters used to prevent browser caching.
Original PR description
Since odoo/odoo@ff53267db5d3, the `unique` parameters previously passed to `/web/webclient/load_menus` has been removed. That commit, also instructed the browser not to store the result, but this is not sufficient; in case a caching proxy sits in between the user and Odoo, it will see the `Cache-Control: public` and still store the result. As a consequence, depending on the caching proxy configuration, it could happen to serve the same menus structure to all users. This commit ensures the intermediaries proxies do not store the result. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257064
This update corrects a bug where new Point of Sale orders were sometimes duplicated after validation, particularly when a default customer was assigned. The fix involves a change in how default partners are handled, ensuring that orders are correctly identified as empty and preventing the creation of redundant orders. This improves order processing reliability.
Original PR description
When a default partner is assigned to new orders, `getEmptyOrder()` failed to find the existing empty order because it filtered on `!order.partner_id`, causing a duplicate order to be created after each validation. Add a `getDefaultPartnerId()` hook returning `null` by default. `createNewOrder()` uses it to assign the default partner centrally, and `getEmptyOrder()` uses it to correctly identify orders still considered empty despite having a default partner set. Also update l10n_ar_pos and l10n_pe_pos to override `getDefaultPartnerId()` instead of `createNewOrder()`. opw-6077656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256618
This update fixes an issue where Point of Sale emails were incorrectly displaying times in UTC for users outside of a store. The change ensures that emails accurately reflect the store's timezone, improving the clarity and usability of order confirmations and notifications. This resolves a potential confusion for users regarding order timing.
Original PR description
The tz variable in POS email templates was set using object.env.user.tz, which resolves to UTC when emails are sent by the Public User. Fix by using `object.company_id.partner_id.tz` instead, which reliably reflects the store's timezone regardless of which user triggers the email. opw-6052244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257822
This update fixes a potential crash in the Point of Sale module. Previously, if the Epson printer IP address wasn't specified, the system would encounter an error. This change ensures the system gracefully handles missing IP addresses, preventing the application from crashing and improving stability.
Original PR description
When `epson_printer_ip` is not set, `isPrivateIp` would crash with "ip.split is not a function" because the value is undefined/null. Add an early return of false when the argument is falsy or not a string. opw-6067382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256028