Tuesday, July 1, 2025
47 changes · saas-18.4
Enhancements to existing features
Romanian chart of accounts labels have been corrected to remove typos and use clearer, more official accounting terminology. This helps Romanian users understand account descriptions more easily and supports better alignment with local reporting guidance.
Original PR description
Description of the issue/feature this PR addresses: Some Romanian translations in the chart of accounts contained typos or imprecise terminology. These inaccuracies could lead to confusion for users relying on the Romanian localization. Current behavior before PR: Several account descriptions in Romanian included spelling errors or used vague or non-standard accounting terms. Desired behavior after PR is merged: Account descriptions in Romanian are now corrected, clearer, and better aligned with official terminology, improving usability and compliance with Romanian accounting norms. The updated translations are based on the official ANAF reference: [SAF-T RO Schema Definition Codes v4.1.6](https://static.anaf.ro/static/10/Anaf/Informatii_R/SAF_T_Ro_SchemaDefinitionCodes_v4_1_6_final_1712021.xlsx) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216358 Forward-Port-Of: odoo/odoo#212477
A new Odoo icon has been added to support the Add Lead button in the VoIP experience. This provides a clearer and more consistent visual cue for users creating leads from VoIP interactions.
Original PR description
This commit introduces a new Odoo icon to complement the "Add Lead" button added in Voip in odoo/enterprise#87294. task-4855486 Requires: - https://github.com/odoo/enterprise/pull/87294  Enterprise: https://github.com/odoo/enterprise/pull/87294 Forward-Port-Of: odoo/odoo#214031
Turkish Nilvera integration connection issues are now recorded as informational messages instead of errors. This keeps automated upgrade checks from failing when internet access is blocked, while still preserving details for troubleshooting.
Original PR description
In 3b5cb63 we silenced Nilvera connection errors to prevent upgrade CI failures due to blocked internet access. However, using `logger.error` still caused CI to fail when triggered. This commit changes the log level to info to ensure the error is recorded without impacting the CI. Also, we're now printing the stack trace for easier debugging. runbot-227039 Forward-Port-Of: odoo/odoo#215791
Accounting report test data now uses the default outstanding payment and receipt accounts created automatically with the chart of accounts. This prevents duplicate account conflicts during validation and helps keep accounting-related releases stable.
Original PR description
In this PR: - As part of recent changes, the default Outstanding Payment/Receipts accounts are now always created when the Chart of Accounts is loaded, and several test cases were updated to avoid unique constraint errors. - Previously, these test cases manually created accounts with codes like `OSTR00` and `OSTP00`. Now that these accounts are created by default, attempts to redefine them or change their codes have led to conflicts. - This commit updates the affected test cases to: - Use the correct default account codes directly (101403, 101404) - Avoid reassignment of codes that are now created by the CoA template task-4826385 Forward-Port-Of: odoo/enterprise#88802 Forward-Port-Of: odoo/enterprise#88068
Resolved issues and error corrections
This fix prevents module installation from failing if the default “Hours” unit of measure was deleted earlier. The system now recreates that required unit when needed and adds protections to avoid the same problem in related planning flows.
Original PR description
Steps to reproduce: --- - Install `sale_management` module - Enable `Units of Measure & Packagings` - Delete `Hours` in Units & Packagings - Install `sale_planning` module Traceback: --- ```…
Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module
Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
<field name="name">planning.role.list.inherit.sale.planning</field>
<field name="model">planning.role</field>
<field name="inherit_id" ref="planning.planning_role_view_tree"/>
<field name="arch" type="xml">
<field name="resource_ids" position="after">
<field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{ 'default_type': 'service', 'default_planning_enabled': True, 'default_planning_role_id': id, 'default_uom_id': %(uom.product_uom_hour)d, }"/>
</field>
</field>
</record>
```
The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.
This commit resolves the issue by calling the `ensure_uom_hours` method before updating the "Hours" unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.
Also restrict deletion of uom Hour in `sale_planning`.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#216715
Forward-Port-Of: odoo/odoo#213293Code cleanup and technical improvements
The website builder’s font selection tool was simplified by removing unused code. This reduces maintenance overhead without changing how users choose fonts.
Original PR description
The font family picker introduced when creating the website builder based on `html_builder` contains some dead code and some useless code. This commit cleans up this component. task-4367641
Miscellaneous changes
Before this commit, printing images in receipt with the web print could not show the images if they are not loaded. This is now waiting for the images to be loaded. Before this commit, if an order preset time was from yesterday, the order could not be cancelled. This is now fixed by changing the condition to accept cancelling orders with a preset time in the past --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214307 For
Original PR description
Before this commit, printing images in receipt with the web print could not show the images if they are not loaded. This is now waiting for the images to be loaded. Before this commit, if an order preset time was from yesterday, the order could not be cancelled. This is now fixed by changing the condition to accept cancelling orders with a preset time in the past --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214307 Forward-Port-Of: odoo/odoo#213988
The website builder now uses the correct internal actions for the Facebook snippet settings. This prevents an error when users add the snippet and open its configuration panel, improving reliability for website editing.
Original PR description
Problem: Dropping the Facebook snippet and interacting with its options caused a traceback due to unregistered or incorrect builder action IDs. Steps to Reproduce: 1. Drop the Facebook snippet in website builder. 2. Click on the snippet to open its configuration panel. 3. Observe the traceback due to unrecognized builder actions. Root Cause: The action IDs used in the XML template (`website.FacebookOption`) did not match the registered plugin action IDs. Fix: Updated the mismatched action IDs in the builder components: * Replaced `checkFacebookLinkAction` → `checkFacebookLink` * Replaced `dataAttributeListAction` → `dataAttributeList`
The website editor now limits header and navigation bar color choices to the intended solid and custom options, avoiding unsupported preset selections. It also lets users properly clear a customized website color so the editor no longer shows a removed color as still selected.
Original PR description
[FIX] website: restrict header navbar colorpicker to solid and custom
Since `html_builder`, the header navbar "Format" colorpicker makes it
possible to pick a preset. This should not be the case.
This commit removes the access to the "Presets" tab for that
colorpicker.
task-4367641
[FIX] website: support removing a customized website color
When `html_builder` was introduced, the `customizeWebsiteColor` action
was created to support assigning colors to specific SCSS variables.
However, it did not support the removal of a previously set color.
This commit handles the removal of such colors.
Note that it assigns no color, which still overrides the initial value.
This is the same behavior as before `html_builder`.
Steps to reproduce:
- select header
- pick a background color
- reset the background color
=> The background color remained selected.
task-4367641Website editors can now click items inside navbar dropdown menus without the menu closing unexpectedly. This makes editing navigation links, including overflow and account menus, smoother and avoids needing to reload the editor.
Original PR description
**Problem** This commit addresses two problems related to navbar dropdown menus closing on click during editing. The first problem concerns the "more" dropdown menu that appears when there are too…
**Problem** This commit addresses two problems related to navbar dropdown menus closing on click during editing. The first problem concerns the "more" dropdown menu that appears when there are too many links. The second problem concerns the dropdown containing the links "my account" and "logout". How to reproduce problem 1: 1. Start editing a page that doesn't have a "more" dropdown in its navbar 2. Click on a navbar link, then click on the "edit menu" icon 3. From the "Edit Menu", add enough menu items to make the "more" dropdown appear (adding mega menu items works too) 4. Click on the "more" button to open the dropdown 5. Click on an item of the dropdown 6. PROBLEM: the dropdown closes 7. Reload the editor, now it works properly How to reproduce problem 2: 1. Start editing a page 2. Click on the username dropdown in the navbar 3. Click on "My Account" or "Logout" 4. PROBLEM: the dropdown closes **Solution** This commit introduces an edit interaction that adds the attribute `data-bs-auto-close: outside` to dropdown elements in the editor. **Note** Some code defining the behaviour of the "more" dropdown is already present in [1] and it is still necessary for the functioning of the dropdown. The newly introduced interaction only fixes a specific case: when new elements are added to the navbar and the "more" dropdown has just been created. In this specific case, the code in [1] does not work properly because the code is executed too soon and the class `editor_enable` is still missing from the body. At the same time, when the editor is opened and the "more" button is already present on the navbar, the interaction fails to set the proper behaviour because the code in [1] replaces the dropdown menu. In this case, anyway, the code in [1] works properly and the dropdown takes the correct behaviour. Probably [1] needs a refactoring, maybe it should be written as an interaction. [1] odoo/addons/website/static/src/js/content/auto_hide_menu.js task-4367641
Payment logs now include both field names and their corresponding values for Stripe payment data, instead of listing only the field names. This improves troubleshooting and support visibility while preserving the existing handling of sensitive data.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Log Stripe payment values. Issue ----- Only the keys get logged. Cause ----- Commit 1a2573881281 fixed the logging of secret keys, but in doing so, only logs keys and no values. Solution -------- Use a dict comprehension to create a full dict to log. opw-4818301 Forward-Port-Of: odoo/odoo#216457 Forward-Port-Of: odoo/odoo#216303
The task header in shared projects now uses the available width correctly, preventing the task status from appearing out of alignment when other fields are hidden. This improves the visual consistency of task forms for portal users accessing project-related sales orders.
Original PR description
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the…
### Steps to Reproduce: 1. Login as Admin user 2. Open project module 3. Share the project 4. Login as Portal user 5. Go to sales order inside the project 6. Open task there you be able to see the state misalignment ___ ### Issue: The task header section (.oe_title) was restricted by a max-width: 75% styling. When the priority field was removed, the remaining fields in the header, particularly the state field, appeared misaligned due to this layout constraint. ___ ### Root Cause: The .oe_title class imposes a max-width that limits the available horizontal space for inline fields in the header. This fixed constraint does not adapt when fields like priority are removed, resulting in layout misalignment. ___ ### Fix: To resolve this, the class mw-100 was added to the `<div class="oe_title"> `element. This overrides the default max-width behavior, allowing the container to use full width when needed. ___ ### Technical Details: This approach keeps layout logic within the view. It also preserves layout flexibility for different screen sizes and future field additions or removals. task-4813557 Forward-Port-Of: odoo/odoo#213085
This change prevents the website donation block from making duplicate background requests when more than one donation section appears on the same page. It improves reliability and avoids unnecessary server calls without changing the visitor experience.
Original PR description
The previous code had a small potential issue: if two instances of the s_donation snippets were present on a page (not sure it happens in practice), then the two interactions would be created, then…
The previous code had a small potential issue: if two instances of the s_donation snippets were present on a page (not sure it happens in practice), then the two interactions would be created, then willStarted. The first one would initiate the rpc, then the second one would do the same, since the cached value was not assigned yet, and only when the first of these 2 rpcs would resolve, then the cached value will be assigned. A possible solution would be to cache the promise instead, but we need to be careful, the waitFor operator will leave a promise pending if the interaction has been destroyed in the time it takes for it to resolve. So, putting in cache a pending forever promise can cause issues. A simple way to solve the issue is to simply remove the waitFor call in willStart, it does not do anything anyway. Another solution is to use the new cached feature from the rpc system. 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 a point of sale loyalty test from running when a related payment-settlement feature is not installed. It avoids false test failures in automated validation, helping keep release checks reliable without affecting customer-facing functionality.
Original PR description
**Problem:** The test was run even when pos_settle_due was not installed, which resulted in an error during the tour, as it looked for a component that did not exist. We now skip the test if pos_settle_due is not installed. runbot-227672 Forward-Port-Of: odoo/odoo#216540
Hungarian electronic credit notes sent to NAV now show the supplier and customer bank accounts correctly instead of duplicating the customer account. This helps businesses avoid incorrect reporting details and improves confidence in Hungarian e-invoicing documents.
Original PR description
### Steps to reproduce: - Install l10n_hu_edi and switch to a Hungarian company - In the settings set the NAV mode to "demo" - Create an invoice to a Hungarian contact with an account number - Send it to NAV - Create the credit note for this invoice - Send it to NAV and download the XML in the page "NAV 3.0" - The account number in `supplierBankAccountNumber` and `customerBankAccountNumber` are the same ### Cause: The code was doing: `'supplierBankAccountNumber': format_bank_account_number(self.partner_bank_id or supplier.bank_ids[:1]),` But for credit notes `self.partner_bank_id` is the bank account of the customer not the supplier. ### Solution: Only use `supplier.bank_ids[:1]`. As the bank account were never tested in l10n_hu_edi, this commit adds it in the setup and changed the XMLs to always test it. opw-4845026 Forward-Port-Of: odoo/odoo#214714
Website visitors no longer see a confusing error caused by certain browser extensions when Odoo's push-to-talk extension is not installed. This improves the browsing experience by safely handling the missing extension case instead of showing an unnecessary traceback.
Original PR description
Scenario: - install website, im_livechat, Metamask external extension - go to any page on the website with chrome Result: a traceback is shown on all pages with no stacktrace and the message "Could not establish connection. Receiving end does not exist.". Issue: the error happen if the push to talk extension is not installed in the pttExtensionHookService. Because of metamask extension, "window.chrome.runtime" is not undefined (if metamask is uninstalled, "the window.chrome.runtime" is undefined). So when metamask (or another extension that cause window.chrome.runtime to be defined) is installed, we get an error shown because the promise rejection is not handled. Fix: handle the unhandled promise error. opw-4874027 Forward-Port-Of: odoo/odoo#216258 Forward-Port-Of: odoo/odoo#216132
This update fixes a failing web test that occurred when demo data was present. It makes the test use its own prepared record, improving reliability for development and quality checks without changing user-facing behavior.
Original PR description
Before this commit, the test TestLoadBreadcrumbs was failing with demo data. After this commit, the test uses a record created during the setUpClass, thus resolving the issue introduced in #212950 .
This fixes an issue in the email testing area where counters could be incorrect during nightly checks. The change helps keep automated quality checks reliable, reducing false failures and improving confidence in releases.
Original PR description
runbot-226551
Middle-clicking a link or action now opens it without triggering cleanup on the page the user is currently viewing. This prevents unsaved work or leave checks from being disrupted when the user is simply opening something in another tab or window.
Original PR description
Before this commit, when middle clicking the clearUncommittedChanges (and subsequently the beforeLeave) were executed on the current controller. This is an issue, as we are not leaving the current controller. Now, the clearUncommittedChanges is not called when middle clicking. Note that, this is already the behaviour if the target is "new". Forward-Port-Of: odoo/odoo#216549
Error dialogs no longer show an unrelated internal request ID in tracebacks. This prevents confusion when users or support teams investigate server action errors, making the reported context more accurate.
Original PR description
Steps: - Enable debug mode - Go to server actions - Create a server action that crashes with `Execute code` - Example -> "a" (will crash because `a` is undefined) - Traceback will contains an invalid ID `Occured on odoo180 on model ir.actions.server and id 19 on 2025-06-30 09:20:48 GMT` This was an error and this ID is not linked with the model, it is the rpc id, so it should not be on the traceback. This commit remove this id to have something like this `Occured on odoo180 on model ir.actions.server on 2025-06-30 09:20:48 GMT` opw-4816514 Forward-Port-Of: odoo/odoo#216553
Invoice forms no longer show an empty line or extra spacing beside invoice amounts when the invoice is not posted or has no outstanding debits or credits. This makes the invoice screen cleaner and avoids visual confusion for users reviewing accounting documents.
Original PR description
Repro steps: Navigate to the form view of an invoice that is either 1. not posted 2. does not have outstanding debits/credits Problem spotted: next to the invoice amounts, a weird line and margin to the right can be seen Cause: The field invoice_outstanding_credits_debits_widget of an invoice may be invisible with this condition invisible="state != 'posted' or not invoice_has_outstanding" and in that case, it's containing group would still be visible (showing the aforementioned margin). Fix: This commit fixes this issue by moving the invisible condition to the group containing the field invoice_outstanding_credits_debits_widget instead of the condition being on the field itself. task-4882509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215119
Fixed an issue where searching security groups using a forward slash could trigger an error instead of returning results. This improves reliability for administrators managing user groups in Settings.
Original PR description
Currently, an error is produced on searching in a security group with a forward slash ('/').
**Steps to reproduce:**
- Navigate to `Settings > Users & Companies > Groups`.
- Type '/' in the search bar and hit Enter.
**Error:**
`IndexError - pop from empty list`
**Cause:**
When the group name contains only slashes, splitting it by '/' at [1] results in an empty list. After computation, it attempts to pop from the empty list, resulting in an error.
[1] - https://github.com/odoo/odoo/blob/a301f8ae6aad59efd073a34c6f9ec323191d211b/odoo/addons/base/models/res_users.py#L234-L235
This commit ensures the group name is only assigned when values have content, preventing the error.
Sentry - 6685124199
Forward-Port-Of: odoo/odoo#216555
Forward-Port-Of: odoo/odoo#214557Urban Piper receipts now show the delivery identifier clearly in the receipt header. This prevents staff and customers from missing or misreading the delivery reference on printed receipts.
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88763 Forward-Port-Of: odoo/enterprise#88113
This update adds test coverage to ensure new employee records are created using the correct company setting. This helps prevent payroll-related validation issues in multi-company environments, particularly for US payroll data.
Original PR description
This commit contains the test for commit f36104c17e0ac3cde788d195aab9394a35545d43 The test is in l10n_us_hr_payroll and not in hr as we need the ssnid constraint task-4897733
This update corrects demo payroll data so Belgian employee records use a Belgium-specific time off type. It prevents access errors when opening affected employee information in the Belgian payroll accounting test environment.
Original PR description
This commit fixes an issue in the demo data. A time off allocation was done using a time off type that is not in Belgium. This caused access error when trying to access the employee. This commit fixes the issue by changing the time off type to a belgian one. task-4896664 Forward-Port-Of: odoo/enterprise#88604
Payslips now print with the correct formatting when a salary rule line is marked as a title. This improves the readability and professionalism of payroll documents shared with employees.
Original PR description
### Steps to reproduce: - Generate and print a payslip after marking a salary rule line as a title. ### Fix: - Added conditional styles and classes to fix the issue. task-4780481 Forward-Port-Of: odoo/enterprise#85607
The Indian payroll demo payslip dates were updated so they fit within the employee contract period. This prevents errors during demo data installation, making setup and evaluation smoother for users.
Original PR description
Issue: The demo payslip for employee had dates before the contract start date, leading to errors during demo data installation. Fix: Adjusted the payslip dates to be 3 months before the current date, ensuring they fall within the employee's contract period and allowing successful demo installation. Forward-Port-Of: odoo/enterprise#86794
The payroll payslip line editing wizard now includes the needed link to its parent wizard when creating new lines. This prevents an error that could interrupt payroll staff while editing payslip details.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88923 Forward-Port-Of: odoo/enterprise#88033
The Journal Report now displays the account name in the Account column, making entries easier to identify and review. This fixes a visibility issue so finance users can understand report lines without needing extra lookup steps.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276 Forward-Port-Of: odoo/enterprise#86113
The Website Help menu now shows only the helpdesk teams linked to the website a visitor is using. This prevents teams from other websites appearing in the wrong place, reducing confusion for customers and staff.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939 Forward-Port-Of: odoo/enterprise#88169
Removing a parent emission source in the ESG app no longer triggers an error. This keeps emission source records editable and helps users maintain ESG data without interruptions.
Original PR description
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new…
Currently, an error occurs when attempting to remove the parent emission source from an emission source. Steps to Reproduce: - Install the `ESG` module. - Go to `Emission Sources` and create a new emission source with a parent emission source. - Remove the parent emission source. `ValueError: Compute method failed to assign esg.emission.source(<NewId origin=3>,).activity_flow_direct_indirect` This error occurs when the parent emission source is removed, causing the scope to become False in _compute_scope[1]. Subsequently, in _compute_activity_flow[2], none of the cases match, which results in a failure to assign the activity flow and raises an error. [1] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L75 [2] https://github.com/odoo/enterprise/blob/1c7620d8de97757abda1993822f92590987bc46c/esg/models/esg_emission_source.py#L77-L78 This commit ensures that if the parent emission source is removed, the activity flow is properly maintained. sentry-6690968543 Forward-Port-Of: odoo/enterprise#88158
Before this commit, the computation of the exclusion of some attributes based on other selected was going through every attribute to determine if it was excluded or not. This is now done once at the loading of the pos. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214243 Forward-Port-Of: odoo/odoo#213789
Original PR description
Before this commit, the computation of the exclusion of some attributes based on other selected was going through every attribute to determine if it was excluded or not. This is now done once at the loading of the pos. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214243 Forward-Port-Of: odoo/odoo#213789
Steps to reproduce: ==================== - Create an invoice - Add a customer whose language differs from the user's language - Create a reversal - Print the PDF Problem: ========= The reversal reference is generated using the user's language, making it impossible to translate properly because the string value is changed and concatenated with the invoice name. Solution: ========== Generate the reversal reference using the partner's language to enable proper translation. opw-474
Original PR description
Steps to reproduce: ==================== - Create an invoice - Add a customer whose language differs from the user's language - Create a reversal - Print the PDF Problem: ========= The reversal reference is generated using the user's language, making it impossible to translate properly because the string value is changed and concatenated with the invoice name. Solution: ========== Generate the reversal reference using the partner's language to enable proper translation. opw-4743430 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215792
In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice This commit solves this issue by using a more precise price subtotal in XML numbers calculations task-4877278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215483 Forward-Port-Of: odoo/odoo#214844
Original PR description
In certain cases, the unit price value on a partial credit note does not match the unit price on the corresponding invoice This commit solves this issue by using a more precise price subtotal in XML numbers calculations task-4877278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215483 Forward-Port-Of: odoo/odoo#214844
**Problem** Before this commit, the `Form` interaction handled visibility calculations inefficiently. Large forms making massive use of visibility conditions could take seconds to be loaded. The function `getFormDataIncludingDisabledFields` (see [1]) was called more often than necessary, leading to the entire form being cloned for every single entry being checked. **Solution** This commit introduces a simple caching mechanism for the form data. The cached value is updated via `getFormDataIn
Original PR description
**Problem** Before this commit, the `Form` interaction handled visibility calculations inefficiently. Large forms making massive use of visibility conditions could take seconds to be loaded. The function `getFormDataIncludingDisabledFields` (see [1]) was called more often than necessary, leading to the entire form being cloned for every single entry being checked. **Solution** This commit introduces a simple caching mechanism for the form data. The cached value is updated via `getFormDataIncludingDisabledFields` only at the setup of the interaction and when receiving user input (debounced). [1] https://github.com/odoo/odoo/pull/213643 task-4367641 Forward-Port-Of: odoo/odoo#216024
**Step to reproduce:** 1. Install l10n_ae module. 2. Create and post a customer invoice with product and Taxes. 3. Print the invoice using the Invoice PDF report. **Issue:** The "VAT" columns in the invoice report for AE localization are left-aligned, which causes a visual misalignment. **Cause:** The header cells for the "VAT" columns use the text-start class, which left-aligns them, whereas the VAT data is right-aligned.It arises because the `<th name="th_taxes">` element
Original PR description
**Step to reproduce:** 1. Install l10n_ae module. 2. Create and post a customer invoice with product and Taxes. 3. Print the invoice using the Invoice PDF report. **Issue:** The "VAT" columns in the…
**Step to reproduce:** 1. Install l10n_ae module. 2. Create and post a customer invoice with product and Taxes. 3. Print the invoice using the Invoice PDF report. **Issue:** The "VAT" columns in the invoice report for AE localization are left-aligned, which causes a visual misalignment. **Cause:** The header cells for the "VAT" columns use the text-start class, which left-aligns them, whereas the VAT data is right-aligned.It arises because the `<th name="th_taxes">` element is aligned with text-end in the base view account.report_invoice_document , but it is overridden for the l10n_ae module with text-start. https://github.com/odoo/odoo/blob/638268a81ed5a292a02d7fc353c4954159de54e1/addons/account/views/report_invoice.xml#L116 **Solution:** To fix this, update the alignment of the "VAT" header columns to use text-end, ensuring consistent alignment. opw-4863313 Before fix:  After fix:  Forward-Port-Of: odoo/odoo#214499
Task: 4640948 Currently, a sales user with no stock permissions can see the little forecast icon and, upon clicking on it, a link to the forecast report. However, trying to access the report results in an "Access Error" message. The forecast report is important for sales users. This commit will allow them to access the report, but without the option to edit stock pickings (reserve/unreserve buttons). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
Task: 4640948 Currently, a sales user with no stock permissions can see the little forecast icon and, upon clicking on it, a link to the forecast report. However, trying to access the report results in an "Access Error" message. The forecast report is important for sales users. This commit will allow them to access the report, but without the option to edit stock pickings (reserve/unreserve buttons). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214567 Forward-Port-Of: odoo/odoo#205513
When doing the following steps: Purchase > Receipt > Landed Cost > Return > Return > Bill The landed cost would prevent the method _generate_price_difference_vals from correctly computing the correct Out Quantity. Hence, even if no stock is actually out, the bill would generate a COGS line for the currency rate difference for the quantity already out. --- ### Test result without fix: ``` 2025-06-25 11:17:39,821 33449 ERROR oes_test_17 odoo.addons.stock_landed_costs.tests.test_stoc
Original PR description
When doing the following steps: Purchase > Receipt > Landed Cost > Return > Return > Bill The landed cost would prevent the method _generate_price_difference_vals from correctly computing the correct…
When doing the following steps:
Purchase > Receipt > Landed Cost > Return > Return > Bill
The landed cost would prevent the method _generate_price_difference_vals from correctly computing the correct Out Quantity.
Hence, even if no stock is actually out, the bill would generate a COGS line for the currency rate difference for the quantity already out.
---
### Test result without fix:
```
2025-06-25 11:17:39,821 33449 ERROR oes_test_17 odoo.addons.stock_landed_costs.tests.test_stockvaluationlayer: FAIL: TestAccountInvoicingWithCOA.test_fifo_return_twice_and_bill_with_landed_cost_and_multi_currency
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/addons/stock_landed_costs/tests/test_stockvaluationlayer.py", line 759, in test_fifo_return_twice_and_bill_with_landed_cost_and_multi_currency
self.assertRecordValues(bill2.line_ids, [
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/odoo/odoo/tests/common.py", line 667, in assertRecordValues
self.fail('\n'.join(errors))
AssertionError: The records and expected_values do not match.
Wrong number of records to compare: 5 records versus 3 expected values.
==== Additional record ====
{'account_id': 388, 'amount_currency': 0.0, 'balance': 25.0}
==== Additional record ====
{'account_id': 406, 'amount_currency': 0.0, 'balance': -25.0}
```
---
OPW-4512411
Origin PR: #199440
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#215900
Forward-Port-Of: odoo/odoo#215827This **PR** enhances the default values for Hungarian electronic invoicing (EDI) by ensuring the delivery date is copied from the original invoice to the corresponding credit or debit note. **task**-4818819 Forward-Port-Of: odoo/odoo#216158 Forward-Port-Of: odoo/odoo#211860
Original PR description
This **PR** enhances the default values for Hungarian electronic invoicing (EDI) by ensuring the delivery date is copied from the original invoice to the corresponding credit or debit note. **task**-4818819 Forward-Port-Of: odoo/odoo#216158 Forward-Port-Of: odoo/odoo#211860
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87714 Forward-Port-Of: odoo/enterprise#87511
Original PR description
Before this commut, the static props of delivery_button was not defined. This commit adds empty static props to the DeliveryButton component. Forward-Port-Of: odoo/enterprise#87714 Forward-Port-Of: odoo/enterprise#87511
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account). With this commit this test works as expected in both of them. (and with/) Caused by: ```py reference_year = fields.Selection( selection='_get_years', string='Reference Year', required=True, default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 e
Original PR description
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account).
With this commit this test works as expected in both of them. (and with/)
Caused by:
```py
reference_year = fields.Selection(
selection='_get_years', string='Reference Year', required=True,
default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 else fields.Date.today().year))
....
def _get_years(self):
today = fields.Date.today()
current_reference_year = today.year + 1 if today.month > 5 else today.year
return [(str(i), i) for i in range(current_reference_year, current_reference_year - 5, -1)]
```
A solution was to use freezetime
runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/226389
Forward-Port-Of: odoo/enterprise#86887Added new translated error messages: - "error_navigation_timeout" - "error_url_redirection" - "error_duplicated_request" Forward-Port-Of: odoo/enterprise#88821
Original PR description
Added new translated error messages: - "error_navigation_timeout" - "error_url_redirection" - "error_duplicated_request" Forward-Port-Of: odoo/enterprise#88821
When sharing a knowledge article with an embedded view to an external user. The view was loading indefinitely without saying that the user doesn't have access to that view. Steps to reproduce: ------------------- * Go to the Planning app * Click the 'gear' icon * Click 'Knowledge' * Click 'Inset view in article' * Select an article to add it to * Share the article with portal user > Observation: Embedded planning keeps loading indefinitely. Works with other views that require acce
Original PR description
When sharing a knowledge article with an embedded view to an external user. The view was loading indefinitely without saying that the user doesn't have access to that view. Steps to reproduce: ------------------- * Go to the Planning app * Click the 'gear' icon * Click 'Knowledge' * Click 'Inset view in article' * Select an article to add it to * Share the article with portal user > Observation: Embedded planning keeps loading indefinitely. Works with other views that require access rights. Why the fix: ------------ Embedded view was loading regardless of the error state. opw-4664036 Forward-Port-Of: odoo/enterprise#87589
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to 0 > Remove the line - Scan XXX #### > The line appear with multiple sublines #### > If you repeat the two last steps even more sublines will appear ### Cause of the issue: Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache: https://github.com
Original PR description
### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to…
### Steps to reproduce:
- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear
### Cause of the issue:
Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.
To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471
opw-4787229
Forward-Port-Of: odoo/enterprise#88439
Forward-Port-Of: odoo/enterprise#87073With this PR: https://github.com/odoo/enterprise/commit/d0659e4bea162d52604910e86a93c38bc3769bf1 The field `totals_below_sections` became uncheckable. The cause was a missing readonly=False on the field task-4894698 Forward-Port-Of: odoo/enterprise#88544 Forward-Port-Of: odoo/enterprise#88491
Original PR description
With this PR: https://github.com/odoo/enterprise/commit/d0659e4bea162d52604910e86a93c38bc3769bf1 The field `totals_below_sections` became uncheckable. The cause was a missing readonly=False on the field task-4894698 Forward-Port-Of: odoo/enterprise#88544 Forward-Port-Of: odoo/enterprise#88491
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remain
Original PR description
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a…
Bug: 1. Worked overtime hours are included within the gross paid amount of a contract rather than being added on top. 2. Casual loading rate applies to Overtime hours. Steps to reproduce: 1. Create a payslip for an employee with a contract of Fixed wage of 2000 per week. 2. The created payslip is of correct amount with the standard 40-hours work week. 3. Add a work entry of type Overtime with duration of 4 hours. Recompute the worked days amounts. Current behavior: The total remains 2000 and the computed hourly rate becomes 2000/44=45.45 Expected behavior: The hourly rate should remain the same 50. The total should increase to be: fixed_wage + hourly_rate * overtime hours 2000 + 50 * 4 = 2200 Fix: 1. While computing the amounts for each worked days type, exclude hours of type Overtime from total hours when calculating the hourly rate. 2.The casual loading rate should not apply to Overtime work entry types. task-4617681 Forward-Port-Of: odoo/enterprise#83171
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 op
Original PR description
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 opw-4824616 opw-4829820 Forward-Port-Of: odoo/enterprise#86831