Daily updates from Odoo
Tuesday, July 1, 2025
74 changes · saas-18.4
New functionality added to Odoo
VoIP users can now open a contact’s related CRM leads directly from the calling interface. This makes it easier for sales teams to connect phone conversations with lead follow-up without leaving the VoIP workflow.
Original PR description
This commit adds a button that connects the contacts to its leads via the VoIP module. It uses the same logic as "Applicant" button introduced before. Task-4855484 Community: https://github.com/odoo/odoo/pull/214031 Forward-Port-Of: odoo/enterprise#87294
Enhancements to existing features
Purchase routing rules can now use either standard receipt or dropship operation types. This makes it easier to configure dropshipping flows separately from regular warehouse receipts, reducing setup confusion for businesses using both processes.
Original PR description
*: stock_dropshipping With this commit ======================== Previously, only 'Receipt' operation types could be selected for rules with the 'Buy' action. However, with a dedicated 'Dropship' operation type, it's now possible to distinguish between standard receipts and dropship flows. This commit enhances the route rule configuration by allowing both 'Receipt' and 'Dropship' operation types to be selectable for 'Buy' actions. Now that 'Dropship' is an operation type, allowing it for 'Buy' rules ensures correct flow setup for dropshipping scenarios. task-4353843
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
The Time Off app now shows a helpful balance banner when viewing an employee's time off from their profile, making remaining leave easier to understand. It also corrects manager access when creating leave for subordinates and fixes balances by excluding expired allocations.
Original PR description
When coming from the time off smartbutton on the employee, having a small banner indicating the number of leaves remaining is useful. This PR adds this banner, the same as in the time off dashboard. The PR also fixes two bugs: - When an employee is a time off manager of another employee, he has access to the time off management menu. There, he can create new time offs for all subordinates employees. The field employee_id had the group hr_holiday_user, which is wrong as the time off managers don't necessarilly have this group. Removing the group allows the time off managers to select the correct employee, and the domain on the employee field ensures that the manager can only select subordinates employees. - In hr_leave kanban cards, the time off balance for that time off type is shown. The amount were incorrectly computed. This PR fixes the issue by filtering out the expired leave allocations. Forward-Port-Of: odoo/odoo#213792
This update refines several website builder controls so users can pick colors, switch builder tabs, and edit links more reliably. It also improves the visual consistency of color pickers and prevents template preview images from being cropped, making page customization smoother and clearer.
Original PR description
### [IMP] html_builder, website: improve color palette select UI This brings back the color palette on two columns and styles closer to what it looked like before [1]. [1]:…
### [IMP] html_builder, website: improve color palette select UI This brings back the color palette on two columns and styles closer to what it looked like before [1]. [1]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4879833 ### [FIX] html_builder: fix colors of theme tab colorpicker Commit [1] was supposed to fix the theme tab in colorpickers, but the variables were set on the wrong element. As the picker's popover is in another part of the DOM, the variables need to be set either on the `html` or the `body` element. [1]: https://github.com/odoo/odoo/commit/4a48b7ce1257 task-4367641 ### [FIX] html_builder: improve focus on builder tabs The `:focus-visible` state on the builder tabs (Add, Edit, Theme) clashed with the highlight styles as the outline did not have the same width and height. Additionally, `:focus-visible` and `:hover` states were incompatible. task-4879833 ### [FIX] html_builder: prioritize link popover over button overlays In the website builder, the button overlays may sometimes appear over the link popover. Adding a sequence makes sure that the buttons will appear first in the DOM order, and therefore under most other overlays. Steps to reproduce: - Drop enough snippets to have a scrollbar. - On the 1st snippet, have an inner column with a small width (just to make sure that the buttons will appear at the "right" place) and a button or a link at the bottom. - Click on the button => The overlay buttons appear over the link popover. task-4879833 ### [IMP] html_builder, web: integrate BuilderColorPicker styles Use dark styles for the BuilderColorPicker, like the rest of the builder interface. task-4879833 ### [FIX] website: do not crop template option We now insert actual images instead of svgs for the "Template" option on dynamic snippets. The alt is also fixed. task-4879833
When an online payment provider is activated, Odoo now automatically assigns the appropriate outstanding account to the related payment method. This reduces manual setup work and keeps payment accounting consistent with the Invoicing module, while excluding manual payment methods without external integrations.
Original PR description
In this PR: - When activating an Online Payment provider that creates a payment.method.line in a journal, automatically assign an Outstanding account to the payment method. - Uses the existing Outstanding Account resolution method from Invoicing module to ensure consistency across the system. - Applied to all Online Payment Providers that rely on provider integration, excluding manual payment providers without external integrations. task-4826385 Forward-Port-Of: odoo/odoo#216364 Forward-Port-Of: odoo/odoo#213554
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
Invoices can no longer be sent by email when the customer has no email address on file. This prevents invoices from being marked as sent incorrectly and prompts users to add the missing email first.
Original PR description
On send and print, When a partner has no email a popup prompts the user to add one but the `Send` button remains active. As a result, the email is sent to an invalid address, and the invoice is incorrectly marked as sent. We should block sending invoices by email if the partner has no email (same behavior as on Sales Orders). Task [link](https://www.odoo.com/odoo/project.task/4882552) task-4882552 Forward-Port-Of: odoo/odoo#215425
Discuss now keeps conversations visually stable while loading and uses smoother scrolling when jumping to the latest message or a specific message. This makes chat navigation feel more polished, especially on slower connections or in long conversations.
Original PR description
Before this commit, jump to present and to message in a discuss conversation was visually unappealing. This comes from: - jump to present scrolling is instantaneous, instead of smooth. - jump to…
Before this commit, jump to present and to message in a discuss conversation was visually unappealing. This comes from: - jump to present scrolling is instantaneous, instead of smooth. - jump to message scroll direction is always from top, when the frequent use-case is jump to older message thus should scroll to top. - message list is empty while the thread is loading, so the slower the connection the most visually unappealing it was. This commit improves scrolling experience with jump to present and jump to message as follow: - jump to present uses a smooth scroll effect similarly to jump to message - jump to message scroll direction is based on whether the message is older or newer to loaded set of messages. - message list stay visually in place while thread is loading. Task-4589532 Before  After 
Payroll runs can now generate payslips from a selected list of employees as well as from existing contract versions. This makes payroll processing more flexible when employee work entries are used and helps ensure the right contracts are selected automatically for the pay period.
Original PR description
Problem ---------- Generation of payslip with valid_versions is not enough flexible With work entries, we have to generate payslips for employees. Objective ---------- Change the _get_valid_versions_domain to _get_valid_versions to get only ids Adapt the signature of generate_payslips to use employees or versions to generate payslips Solution ---------- Now the _get_valid_versions give the valid versions ids, so we can directly browse them or add them in a domain, the domain is not forced The generate_payslips can work with versions (first argument by default) and employees, if employee_ids are given, this will fetch valid versions for these employee depending on the pay run config directly. So via the front, we can call generate_payslips with a list of employees if we don't have versions directly. (it will automatically select all contracts valid in the range of payrun as before with contracts) task-4900019
Users registering SEPA Direct Debit payments now see a banner listing any partners who do not have a valid SEPA mandate. This helps staff quickly identify which customer records need attention before payments can be processed.
Original PR description
When users try to register one or multiple payments with 'SEPA Direct Debit' method, and one or more partners don't have a valid SEPA mandate, a banner alerts the user and mention the names of the concerned partners. This makes it easier for the user because he directly sees the partners for which he has to set a SEPA mandate. task-4575537 runbot : https://runbot.odoo.com/runbot/bundle/18-0-sepa-missing-links-roto-353391 Forward-Port-Of: odoo/enterprise#81019
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
HR users can now open the employee contract version linked to a partially signed offer in a read-only view before countersigning. The signed contract button also consistently opens the correct version, including after a page refresh, reducing confusion during contract review.
Original PR description
New Versions tied to partially signed contracts are now read-only. A smartbutton for HR to view the employee version before countersigning. The smart button exists within the offer form view when the offer is partially-signed, it redirects to a read-only view of the employee version based on the partially signed contract. Fixes When the contract is countersigned, clicking on the "signed contract" smart button now leads to the correct version view. When the page is refreshed, the correct version is still loaded. Task-4873800
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#213293The 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`
Employee creation now uses the employee's actual company from the start, preventing company-specific rules from being checked against the wrong organization. This reduces errors in multi-company setups, especially where HR rules depend on country-specific company settings.
Original PR description
=== Problem === Both hr_employee and hr_version have a stored field 'company_id'. The hr_version company_id field is a computed field that depends on the company_id field of the employee, if there is an employee (i.e. it is not a contract template). The problem is: when we create a new employee, the company_id field of the version will first be the current company, not the one of the created employee. This causes some problems, for example the constraints related to the company's country being wrongly executed on the hr_version. === Solution === To solve this problem, we explicitely set the correct company in the context when creating new employees, so that the version created by the ORM will have directly the correct country. These are batched by company to avoid loss in performance. task-4897733
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
Fixes an error that occurred when users uploaded a vendor bill PDF from the Requests for Quotation list. This restores the expected bill upload flow for purchase teams and prevents a blocking traceback during invoice creation.
Original PR description
In e7c93e5a6 we modified the call signature of `AccountMove._extend_with_attachments()` Now it takes not an `ir.attachment` recordset, but a list of dicts. But we forgot to modify the calling code in `PurchaseOrder.action_create_invoice`. As a result, the 'Upload Bill' button is currently broken. Steps to reproduce: - go to Purchase > Requests for Quotation - select a purchase order in the list view - click on `Upload Bill` and upload a PDF -> a traceback occurs.  This PR fixes the calling code in `action_create_invoice`. task-none
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 fix restores a backup preview frame in the website builder so the previous page remains visible while a new page loads. It reduces distracting white flashes during navigation, making the editing experience feel smoother and more polished.
Original PR description
Since we refactored the website builder, the iframe fallback feature was lost: it is a second iframe that is useful to display the previous screen while we navigate from a page to another, so we reduce the white flash effect 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 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
Sales involving another company no longer fail when the user is limited to one allowed company. The fix ensures stock routing and delivery locations are handled correctly for intercompany transfers, preventing order confirmation errors and improving continuity for sales and warehouse teams.
Original PR description
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another…
**Steps to reproduce the issue:** - Install Stock, Sales applications - Set the allowed companies to Marc Demo to be only one company - Change the user to Marc Demo - Create a SO with partner another company than Marc's company - Confirm the SO **Issue:** A traceback is raised: `No rule has been found to replenish "product" in "Virtual Locations/ Inter-company transit". Verify the routes configuration on the product.` **Root Cause:** - When the procurement group searches for a pull rule with a destination location set to the inter-company transit location (due to the partner's company being different), the rules for the inter-company transit location are not automatically applied. - The `_get_rule_domain` method https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_rule.py#L641-L653 modifies the destination location to the customer's location if: - The user belongs to the `base.group_multi_company` group. - The destination location is the inter-company transit location. - In this use case, the user does not belong to the `base.group_multi_company` group because they are restricted to a single allowed company. Additionally, the logic in `_compute_location_dest_id` https://github.com/odoo/odoo/blob/05cff3b7d866f6bc95c4b32f343ae14a4da946f2/addons/stock/models/stock_move.py#L227-L231 for inter-company transfers does not account for users with a single allowed company. **opw-4749870** 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#216317 Forward-Port-Of: odoo/odoo#211063
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
This fix prevents manually edited vehicle information from being overwritten during upgrades from earlier Odoo versions. It makes the fleet upgrade behavior safer and more reliable when new vehicle fields are introduced.
Original PR description
Description of the issue this PR addresses: When migrating from 18.2 to 18.3, certain vehicle fields (e.g., `category_id`) are unexpectedly reset. This issue is caused by the introduction of new field(s) in the vehicle model in 18.3 that share a common `_compute` function with existing fields. The shared `_compute` method updates all fields listed in `MODEL_FIELDS_TO_VEHICLE`, which unintentionally overwrites existing values, even those that have been manually edited, during the migration. While this could be mitigated by explicitly adding the new fields using `util.create_column(...)` in the upgrade script, a more robust and maintainable solution is to separate the compute logic for each field. This prevents unintentional side effects when new fields are added in the future and reduces dependency on strict upgrade scripts. Forward-Port-Of: odoo/odoo#215241
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
Portuguese accounting now shows the expected local account names for cash and demand deposits, making the chart of accounts clearer for Portuguese companies. The update also keeps point-of-sale setup working by finding the default cash account reliably regardless of the user's language.
Original PR description
**PROBLEM** The account Caixa (Cash) and Depósitos à Ordem (Demand deposits) are missing from the Portuguese localization. The accounts numerario and banco exist, but they don't have the right names. **STEPS TO REPRODUCE** - install the accountant and l10n_pt module. - select a Portuguese company and select the portuguese language. - in the Chart of Accounts, notice there is no account named Caixa and Depósitos à ordem. **FIX** We still need to translate "Bank" by Banco in some context. We override the "Bank" and "Cash" account in the pt journal template, using the account.account-pt.csv data. opw-4829413 related PR: https://github.com/odoo/odoo/pull/213522 Forward-Port-Of: odoo/odoo#216420 Forward-Port-Of: odoo/odoo#215369
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
Users working from a branch could hit an access error when opening Profit & Loss reports if a parent-company journal used a different currency. The fix lets Odoo safely read the needed currency information so authorized users can view accounting reports without requiring settings permissions.
Original PR description
### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Forward-Port-Of: odoo/odoo#215455
Reverts a recent web change that could cause some databases to show a blank screen due to a browser script loading error. This restores safer behavior while the underlying asset processing issue is investigated.
Original PR description
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown,…
**What's the issue?** On multiple database instances, there is a blank screen appearing with a console error: unknown token 'export' **Why is it happening?** While the exact reason is still unknown, here are the main cuplrits: [this first commit](<https://github.com/odoo/odoo/pull/213223/commits/d4c7e7abbde31806a49d4cdba340cd238eb9130b>) and [this second commit](<https://github.com/odoo/odoo/pull/213223/commits/f7426b366431ebc6266113700eeb3821e9e6a884>). The first commit adds support for '$' characters in JS variable names, while the second takes advantage of that feature to declare short-hand aliases for the Hoot-DOM library. The issue is caused because the aliases from the second commit seem to have been applied to the static assets (and it also seems that they have been correctly transpiled by the server), but for some reason the transpiler still doesn't support '$' characters and ignores the added export statements. Database server code has been verified as having the correct version of the transpiler code, but the resulting static assets still present this issue. **What can be done?** This PR should fix the issue, as it effectively reverts changes on the second commit. The first commit has not been reverted (yet), as the cause of the issue is still unknown, and the damage need to be mitigated as quickly as possible. A temporary fix while the revert arrives in stable is to head to the crashing DB in `debug=assets` mode, to head to the debug menu (Bug icon) and to `"Regenerate Assets"`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216626
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
Checkout no longer fails when a customer selects a warehouse pickup location that has no postal code. This prevents lost sales in countries or locations where postal codes are optional.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Enable `website_sale_collect`; 2. set up a warehouse in a country with optional zip codes; 3. configure warehouse as a pickup location; 4. add products…
Versions -------- - saas-18.3+ Steps ----- 1. Enable `website_sale_collect`; 2. set up a warehouse in a country with optional zip codes; 3. configure warehouse as a pickup location; 4. add products to its inventory; 5. via eCommerce, go to one of these products; 6. select warehouse as pickup location; 7. go to checkout; 8. attempt to pay for the order. Issue ----- Rendering error due to attempting to using `+` on strings & bools. Cause ----- Commit e3230547a53ce added a "Deliver to pickup point" line where it concatenates pickup location values into a single string like https://github.com/odoo/odoo/blob/8103619c51525bcdaa754c39c7d27560b3f6861e/addons/website_sale/views/templates.xml#L2686 The intention is that if the key doesn't exist, the empty string should be used. Issue is that when no zip code is provide, using `get` will return the boolean `False` instead of falling back on the empty string, leading to the rendering error. Solution -------- When sending the pickup location data to the front-end, provide empty strings instead of boolean values. opw-4893036 Forward-Port-Of: odoo/odoo#216112
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
Salary offer forms now keep the correct signature template information when contract versions are loaded, preventing an error during submission. Applicant stage display behavior was also adjusted so hiring status steps remain visible more consistently.
Original PR description
By assigning the contract_template_id to version.contract_template_id when it's loaded and assigned to hr.employee.contract_template_id This prevents the error: "No signature template defined on this version.." when trying to submit the salary configurator form. task-4873800
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#214557Time off approvers assigned on an employee record can now approve or refuse leave requests dated in the past. This fixes a workflow issue so managers can correctly process older or backdated time off records without extra intervention.
Original PR description
With this commit, a time off approver (define in employee form) can approve/refuse a past leave. task-4868496 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#215405
Urban 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
Sales Planning now installs correctly even if the standard Hours unit of measure was previously deleted. The system recreates the needed unit when required and prevents it from being removed in this context, reducing setup failures for customers using planning and sales features.
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.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261
Forward-Port-Of: odoo/enterprise#89046
Forward-Port-Of: odoo/enterprise#85286This 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
Fixed an issue where discounts on regular sales order lines could be unexpectedly removed when a subscription order was saved or closed. This helps ensure quoted and invoiced discounts remain accurate for customers using subscriptions alongside one-time products.
Original PR description
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines…
**Issue 1** - Have a pricelist with the "Discount policy" == "without_discount" - Using this pricelist, create a SO with 1 subscription line and 1 non-subscription line - Set a discount on both lines - Save the SO - Issue: the discount on the non-subscription line has been reset to 0.0 **Issue 2** - Using the previous SO, add back a discount value for the non-subscription line - Confirm the SO and invoice it - Close the subscription - Issue: the discount on the non-subscription line has been reset to 0.0 **Cause** Both issues come from the fact that `order_id.subscription_state` is a dependency of `_compute_discount` in `sale_subscription`. The super is called for non-subscription lines, recomputing the discount. **Solution** It is not possible to know which dependency triggered the compute, therefore the solutions are to: - avoid a recompute at creation after the `web_save` by not writing on the `subscription_state` field if not necessary - avoid calling super for lines if the subscription is closed opw-4645579 Forward-Port-Of: odoo/enterprise#88816 Forward-Port-Of: odoo/enterprise#84754
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
Chile POS users now see the actual outstanding invoice amount when settling customer invoices, instead of an incorrect default of $1. This prevents undercharging mistakes and helps cashiers complete settlements accurately.
Original PR description
**Problem:** When trying to settle an order in POS with a Chilean company, the amount to be settle will be 1$, regardless of how much needed to be settled. **Steps to reproduce:** - Set the company to a Chilean company. - Make an invoice for a Chilean customer and confirm it. - Go to pos, and click settle invoices for your client, chose the invoice you just made. - The amount will be 1$ **Why the fix:** The field *pos_amount_unsettled* was not loaded into the invoice if the company is from Chile. It resulted in it being undefined, thus it was set to 1 afterwards. We now load this variable into the invoice when loading the data. opw-4856764 Forward-Port-Of: odoo/enterprise#87881
Employees can now open and sign custom salary contract offers generated from contract templates. The fix ensures the signing link uses the correct signer-specific access information, preventing blocked or broken signing flows.
Original PR description
Steps to Reproduce: - Create a new contract template. - Define signatories to it(pref: employee) - create a offer linked to an applicant and try generating a offer and signing Fix: - Since the sign creating new role every time when we add new signer, we can't use the existing employee role id anymore. - Hence we will get the access token from signatory linked with the signer in the contract template and use that. task-4894597 Forward-Port-Of: odoo/enterprise#87420
Spreadsheet dashboards now treat creation date filters as date-and-time values, so results better reflect each user's timezone. This prevents dashboards such as CRM leads and HR referrals from including or excluding records around day boundaries incorrectly.
Original PR description
The generated domain is wrong when filtering on the date. It doesn't account for the user timezone because the field matching is given as a "date" field instead of being a "datetime".
The generated domain looks like `[("create_date", ">=", "2025-06-27")]` instead of `[("create_date", ">=", "2025-06-27 21:59:59")]`
I'm fixing this in 18.0 because this fix won't affect existing databases (without updating the modules). The fix would be useless and I don't want to go though the pain of forward-ports for nothing. New databases are created in 18.0 every day (latest LTS)
Task: 4903362
Forward-Port-Of: odoo/enterprise#88807
Forward-Port-Of: odoo/enterprise#88730This fixes an access error that could prevent certain branch users from opening Profit and Loss reports when journals belonged to a parent company with a different currency. The report can now display the needed journal information without requiring those users to have broader company settings permissions.
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455 Forward-Port-Of: odoo/enterprise#88848 Forward-Port-Of: odoo/enterprise#88339
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
Code 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
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