Daily updates from Odoo
Wednesday, June 17, 2026
225 changes
19 changes
Enhancements to existing features
This update ensures Odoo sends the LC116 code with dots, as required by Avalara's integration tool. Currently, Odoo removes these dots, which prevents Avalara from properly sanitizing the data. This change improves compatibility with Avalara's service.
Original PR description
Purpose: Avalara requires the LC116 code to be dotted for certain city webservices. Their tool will automatically sanitize the dots for cities that don't support it. Current Behavior: Odoo sanitizes the LC116 code before sending the JSON payload. Expected Behavior: The LC116 code is sent in the JSON payload with the dots. task-6304351 Forward-Port-Of: odoo/enterprise#120648
Resolved issues and error corrections
This update refines the controller for importing bank statements, addressing previous issues caused by shared logic with the general accounting module. By using a more targeted controller, we've streamlined the process and ensured accurate bank statement handling.
Original PR description
account_bank_statement_import_view was using the same controller used in account.move which caused some wrong behavior when some logic isn't shared between both modules, now account_bank_statement_import uses a generic controller that doesn't add unneeded behavior. As well as removing all of the account move classes from bank statement import and using generic ones or ones specific to account bank statement import. task-5892419 Forward-Port-Of: odoo/enterprise#117476
This update fixes a potential issue where errors during payment processing would display a traceback to users. Now, errors are handled silently, ensuring a smoother experience for users who have already initiated a 'force done' payment. Additionally, a timeout has been added to Cashdro requests to quickly identify and address problems caused by incorrect IP addresses.
Original PR description
In odoo/odoo#268496, a fallback was added to automatically cancel the payment when forcing it, to avoid the cash machine getting stuck with a payment in progress. However, if an error occurs with this cancel request, it causes a traceback to appear. In this commit, we now catch the error from the cancellation, and don't show it to the user at all since they have already force completed the payment. We also add a timeout to Cashdro requests to fail faster when using a wrong IP (e.g. 1.2.3.4). task-6307491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270339
This update resolves a crash that occurred when adding reactions to messages on smaller screens. The fix ensures the correct action object is passed, preventing errors and improving the user experience across different screen sizes. This enhances usability for all users.
Original PR description
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash: ``` Cannot destructure property…
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:
```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
at Proxy.onSelected
```
This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.
This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.
[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84
Forward-Port-Of: odoo/odoo#270158This update fixes an issue where capitalized email domains in aliases caused emails to be misrouted. The change prevents users from saving capitalized domain names, ensuring emails are correctly processed and delivered. This resolves a technical problem that could impact email delivery reliability.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257792This update corrects a bug where selection fields in the Odoo Studio were incorrectly marked as required by default. The fix ensures that selection fields are only required when explicitly set to 'true', improving usability and preventing accidental data entry errors. This resolves a previous issue impacting Studio workflow.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503 Forward-Port-Of: odoo/enterprise#120037
This update corrects a bug where submitting the Contact Us form incorrectly updated both the new task and existing tasks with the wrong customer information. The fix ensures that task customer information is correctly linked to the project, preventing unintended partner updates and maintaining data accuracy.
Original PR description
Steps to reproduce: -------------------------------------------- 1. Install `website_project` module 2. Create a new project 3. Add a customer to the project 4. Go to customer > add email and phone…
Steps to reproduce:
--------------------------------------------
1. Install `website_project` module
2. Create a new project
3. Add a customer to the project
4. Go to customer > add email and phone
5. Create a new task in that project:
* Observe that the customer is the same as the project
6. Go to Website > Contact Us > Edit > Click on submit button
7. Set action to 'Create a Task' and select the created project in 'Project'
8. Click on Save and Open the URL in Incognito Mode
9. Go to the Contact Us page > Fill in the details > Submit
10. Comeback to our window and open tasks of the created project
Observation:
--------------------------------------------
1. A new task is created using the customer details entered in the form.
2. The existing task’s customer and the project’s customer are also incorrectly updated to this new customer.
Issue:
--------------------------------------------
The bug is in the `extract_data` method of the website form controller for projects.
A non-logged-in user submits the Contact Us form with name and an email that doesn't match any existing partner. The old code's `else` branch would set `partner_name` in the task record values without setting a `partner_id` https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/controllers/main.py#L65-L66
During task creation, the computed field `_compute_partner_id` automatically sets `partner_id` to the project's partner
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/project/models/project_task.py#L1440-L1441
`partner_name` is defined as
https://github.com/odoo/odoo/blob/cd080047578b9992811608a5af73a982a414da39/addons/website_project/models/project_task.py#L12
In Odoo, a related field is essentially a shortcut to a field on a linked record The key attribute here is `readonly=False`. This tells Odoo:
* On read: Get the value from `self.partner_id.name`
* On write: Propagate the write back to `self.partner_id.name` (this is the inverse). So writing `task.partner_name = 'TEST'` is equivalent to writing `task.partner_id.name = 'TEST'`. It modifies the partner record itself, not just the task.
So, the partner record itself was renamed. Every record that references a partner now sees the new name
Solution:
--------------------------------------------
The fix passes `False` to `partner_id`, this way:
* The existing partner is untouched
* All other tasks and the sales order keep their correct customer
opw-6206080
Forward-Port-Of: odoo/odoo#270157
Forward-Port-Of: odoo/odoo#264738This update resolves an issue where multiple Oboxes connected to a database weren't all displaying a green Websocket status in the Kanban view. Now, all connected Oboxes show the correct status, ensuring accurate monitoring of Obox connectivity.
Original PR description
Before this commit, if you had multiple Oboxes connected to a DB, and you looked at them in the Kanban view, only 1 Obox would show a green status for Websocket, despite all of them being connected. After this commit, the Websocket status for each Obox is green as expected. Forward-Port-Of: odoo/enterprise#120828
This update fixes an issue where tags and input fields were overlapping in the SelectMenu, particularly when multiple selections were made. The change ensures tags and the input field are always displayed on separate lines, improving readability and usability for users. This resolves a minor visual inconsistency.
Original PR description
Before: With multiSelect enabled, tags appear on the same line as the input, shrinking it. After multiple selections, the input wraps to the next line inconsistently. After: Tags and the input are always on separate lines. task-5226503 Forward-Port-Of: odoo/odoo#269497
This update resolves a technical problem preventing the Odoo upgrade command from functioning correctly when running Odoo in standalone mode. The fix addresses issues with argument handling and the system's path configuration, ensuring the upgrade process now works reliably. This improves the stability of our standalone Odoo deployments.
Original PR description
The command no longer works in standalone mode due to the following issues: - Each access to `self.parser` creates a new parser, so previously added arguments are lost. - The parsed `addons_path` value is already a list, but the command attempts to split it again. - The temporary Odoo paths remain in `sys.path`, causing Odoo modules to shadow standard library modules when running upgrade scripts. This commit addresses all the above issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269931
This update resolves an issue where the Facebook statistics refresh process would fail due to a calculation error when data was unavailable. The fix prevents a 'None' value from causing a calculation error, ensuring statistics are consistently updated. This improves the reliability of Facebook integration for users.
Original PR description
Traceback: ```py TypeError: unsupported operand type(s) for -: 'NoneType' and 'int' ``` Cause: https://github.com/odoo/enterprise/blob/f6c5ce7de737794a675d1b2485dd5c1a9ed0cb17/social_facebook/models/social_account.py#L92-L108 ``meta_run_request_batch()`` may return ``None`` for failed requests. In that case, ``page_global_stats`` is ``None``, leading to ``fan_count`` being ``None``. The statistics computation then calls ``_compute_trend()`` with a ``None`` value, causing the above traceback. https://github.com/odoo/enterprise/blob/f6c5ce7de737794a675d1b2485dd5c1a9ed0cb17/social/models/social_account.py#L143-L144 sentry-7545763666
This update fixes several visual issues within the Odoo spreadsheet component, specifically addressing problems with dark mode display and usability. The changes improve the spreadsheet's appearance and functionality, ensuring a consistent and readable experience across different themes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e061163e2e [REL] 19.3.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e061163e2e [REL] 19.3.7 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/0d81fad529 [FIX] Headers overlay: unhide headers in dark mode [Task: 6233467](https://www.odoo.com/odoo/2328/tasks/6233467) https://github.com/odoo/o-spreadsheet/commit/8eaa180d01 [FIX] autofill: make tooltip readable in dark mode [Task: 6289977](https://www.odoo.com/odoo/2328/tasks/6289977) https://github.com/odoo/o-spreadsheet/commit/0e6b5108a9 [FIX] pivot: hide collapse icon when displaying formulas [Task: 6218524](https://www.odoo.com/odoo/2328/tasks/6218524) https://github.com/odoo/o-spreadsheet/commit/d5547b637d [FIX] side_panel: autocomplete dropdown transparency issue on scroll [Task: 6254807](https://www.odoo.com/odoo/2328/tasks/6254807) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent update to the Weblate translation system unexpectedly reverted some code changes. This pull request is correcting this issue by restoring the original code. This ensures that all features continue to function as designed after the translation update.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit 3c73ba831077e166d1dbaf6003ba0d735469f5f9.
This update significantly speeds up inventory adjustments when processing large delivery orders with reserved packages. Previously, adjustments were slow and could freeze the user interface. Now, inventory changes are processed much faster and more reliably, improving warehouse efficiency and user experience.
Original PR description
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse…
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts. Behavior after: Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation. Root Cause: When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing. Fix: Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries. Steps to Reproduce: 1. Have a product tracked by Lot and Package. 2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line. 3. Go to Inventory → Physical Inventory. 4. Set the counted quantity of any reserved bag to 0. 5. Click Apply. 6. Observe that the system takes time to process this single change. 7. Unreserve the delivery order. 8. Perform the same steps as mentioned above. 9. Inventory adjustment is much faster. opw-6234885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270228
This update resolves an issue where automatic payment terminal integration prevented users from correctly splitting bills. Now, users can manually set the payment amount or use the original 'Send' button, ensuring accurate handling of all payment types within Point of Sale.
Original PR description
Using payment terminals, we automatically send the transaction to the terminal to avoid a click on "Send", but this prevents from setting an amount to send for split bills. We now let the user set an amount, or directly click on "Send". see odoo/enterprise#120672 task-6303855 Forward-Port-Of: odoo/odoo#270240
A recent issue causing the Documents view to crash when accessed through an activity has been resolved. This was due to a timing problem with how the system processed data, leading to an error when trying to set the 'COMPANY' field. This update ensures the Documents view functions reliably.
Original PR description
### Description When navigating to Documents via an activity, the list view crashes with a TypeError on setting 'COMPANY'. ### Root Cause An asynchronous race condition occurs between parent and child `onWillStart` hooks. The child finishes an await before the parent's hook runs `expandDefaultValue()`. Thus, `this.state.expanded[sectionId]` is undefined when the child tries to write to its nested keys. ### Solution Await `sectionsPromise` first in the child hook. opw-6276003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#120713 Forward-Port-Of: odoo/enterprise#119634
This update simplifies accessing employee profiles from the avatar card. Previously, a confirmation dialog forced users to activate inactive companies. Now, a 'View Profile' dropdown offers two options: directly opening the employee profile (activating the company) or accessing the contact profile without company activation. This provides a smoother user experience and avoids unnecessary company activations.
Original PR description
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the…
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the other company or cancel, with no way to reach the still-accessible contact profile. Replace the dialog with a less intrusive "View Profile" dropdown, shown only when the employee's company is allowed but not active. It offers two choices: - Open Employee Profile (activates the company) - Open Contact Profile (no company activation) Activating an extra company widens the active-company scope for the whole session, which is not always desirable, so keeping a non-mutating path to the contact profile is useful. In every other case (no employee, company already active, or company not allowed) the plain "View Profile" button is unchanged. task-6074597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270312 Forward-Port-Of: odoo/odoo#264073
Features or functions removed from Odoo
This update removes a redundant payment feature related to payment terminals. The removal of fast payments using these terminals made the associated override unnecessary, streamlining the system. This change improves efficiency and reduces potential complexity.
Original PR description
We removed fast payments using payment terminals, making the `fastPayments` method override useless. see odoo/odoo#270240 task-6303855 Forward-Port-Of: odoo/enterprise#120672
Code cleanup and technical improvements
This update streamlines the account module's code by creating reusable JavaScript classes and removing unnecessary conditional statements. These changes improve the module's efficiency and stability, ensuring consistent behavior across different account processes.
Original PR description
Made some generic JS classes that can be used between account move and account bank statement and removed some if statements that are no longer needed from account_tree controller because they were used to bypass default behavior if used by a model other than the intended one. This issue was fixed in: https://github.com/odoo/enterprise/pull/117476 task-5892419 Forward-Port-Of: odoo/odoo#264775
33 changes
Enhancements to existing features
This update introduces a new automated process that runs every Sunday to reset configuration settings related to development tools (devtools). This ensures that features disabled for production are automatically re-enabled at the start of the week, streamlining the update process. It's a routine maintenance task.
Original PR description
We add a new cron to re enable disabled features by unsetting devtools keys in configuration. This cron is meant to run every sunday at the end of the day, right before the monday update.
This update connects Odoo to your Gmail account via a new Chrome and Firefox extension. It automatically captures email details (sender, recipients, etc.) related to projects and tasks, and then suggests these emails as key events within the timesheet grid. This provides a more complete record of work activity.
Original PR description
[IMP] timesheet_grid: Gmail watcher In this commit, Odoo now consumes data from the new Gmail Chrome and Firefox web extension, which captures the from, to, cc, and bcc fields of read and composed emails and sends them to Activity Watch. Odoo retrieves these events, extracts the emails, searches for partners linked to projects and/or tasks, and adds them to suggestions as keyEvents. task-5956040 Forward-Port-Of: odoo/enterprise#112014
Resolved issues and error corrections
A recent upgrade process caused an error when users accessed the partner page after updating to version 19.2. This was due to a change in how website templates handle titles. This fix ensures the website remains accessible after upgrades by preserving the necessary configuration elements.
Original PR description
**Issue:** Currently, an error occurs when users access the `/partners` website page after upgrading a database with the `website_crm_partner_assign` module (including demo data) to saas-19.2. **Root…
**Issue:**
Currently, an error occurs when users access the `/partners` website page
after upgrading a database with the `website_crm_partner_assign`
module (including demo data) to saas-19.2.
**Root cause:**
This issue occurs because recent changes introduced in PR [1] added a
new template as id `index_layout`. Inside this template, a `t-call` element
was using a nested `t-set` element to define `additional_title`. We were
referencing this `t-set` element in the XPath of the `index` template to
override the value of `additional_title`.
However, recent changes removed the `t-set` from the `t-call` and replaced
it with a direct variable assignment inside the `t-call`. During the upgrade,
the migration script automatically moves the `additional_title` attribute
into `t-call` and removes the `t-set` from the `t-call` (see the script and
related changes in [2]).
As a result, the XPath expression that targets the `t-set` element fails
because the referenced element no longer exists, which causes the error.
**Solution:**
This commit fixes the issue by moving the `t-set` element outside the `t-call`
and passing its value as an attribute of the `t-call` during the upgrade.
The `t-set` element is preserved to maintain compatibility with custom `XPath`
expressions that may target it, prenet XPath target errors after the upgrade.
The upgrade-specific behavior is enabled only when `config.get('upgrade_path')`
is set, allowing the code to detect that it is running in an upgrade context.
[1]: https://github.com/odoo/odoo/commit/711c3baad58f3e0f1dc39cb90eb8176aba91e9dd
[2]: https://github.com/odoo/odoo/pull/235469/changes#diff-29ae6f0bcf846a2fcaffc38fdd0d3b19ea328c133ff4dfe18cc9725715f34dd9
Sentry-7400315548This update fixes an issue where order-level customer notes weren't appearing on preparation tickets. The fix ensures that these notes are now printed, improving communication between the front-of-house and kitchen staff. It also prevents unnecessary tickets from being generated when order notes are updated.
Original PR description
Steps to Reproduce: - Open Restaurant POS configured with a preparation printer. - Create a new order and add a customer note at the order level. - Send the order for preparation. Issue: - The order-level customer note is not printed on the preparation ticket. Fix: - Ensure the customer note is included in the preparation ticket. - Prevent additional preparation tickets from being printed when the customer note (or internal note) is modified alongside order lines. Task-5960046
This update fixes an issue where tags and input fields in the Select Menu were overlapping, particularly when multiple selections were made. Now, tags and the input field are always displayed on separate lines, improving the user experience and ensuring the Select Menu takes up the correct amount of space.
Original PR description
Before: With multiSelect enabled, tags appear on the same line as the input, shrinking it. After multiple selections, the input wraps to the next line inconsistently. After: Tags and the input are always on separate lines. task-5226503 Forward-Port-Of: odoo/odoo#269497
This update fixes an issue where long text labels in SelectMenu multi-select tags would overflow, creating a poor user experience. Now, tags are automatically truncated to fit, aligning with how Many2ManyTags display, ensuring consistent and readable selection options.
Original PR description
Before: Tags in SelectMenu (multi-select) had no text-overflow handling. After: Tags now truncate text, consistent with Many2ManyTags behavior. task-5226503 Forward-Port-Of: odoo/odoo#269563
This update fixes a minor visual issue in the Web Studio interface. Previously, property tags within SelectMenu widgets were constrained to a limited width, leading to unused space. Now, tags automatically expand to fill the available width, creating a cleaner and more user-friendly experience.
Original PR description
Before: Each tag was limited to 200px, leaving available space unused. After: Each tag now expands to 100% of the available width. task-5226503 Forward-Port-Of: odoo/enterprise#120260
This update corrects a bug where selection fields within Odoo's Studio were incorrectly treated as required. The fix ensures that selection fields are only required when explicitly marked as such, improving usability and preventing accidental data entry errors. This change enhances the overall Studio experience for business users.
Original PR description
Before: any studio property using a SelectMenu (selection) component, without a `required: false` in the childProps, was implicitly required because the check used `required !== false`, which evaluates `undefined` as truthy. After: `required` is only applied when explicitly set to `true`. task-5226503 Forward-Port-Of: odoo/enterprise#120037
This update resolves an issue that caused a traceback when users deleted the last column from a table within the Odoo Report Editor. The fix prevents a technical error by ensuring the editor handles the scenario where a table has no remaining columns gracefully. This improves the overall stability and reliability of the report design process.
Original PR description
Problem: When deleting the last column in a table in studio we get a traceback. Cause: `firstCell` will be null if we delete the last cell in the table. Fix: Added a null check on `firstCell` before calling `setCursorEnd`, so the cursor is only repositioned when the table still has remaining cells. Steps to reproduce: - Edit a report with a table. - Remove all columns. - Traceback will occur when deleting the last one. opw-6263696 Forward-Port-Of: odoo/enterprise#119502
This update fixes an issue where Odoo cron workers weren't efficiently managing memory usage. By introducing a new configuration option, `ODOO_REGISTRY_LRU_SIZE_CRON`, we can now set a lower memory limit specifically for cron workers, preventing excessive registry cycling and optimizing performance. This ensures smoother operation for background tasks.
Original PR description
The configuration option `registry_lru_size` does not exist and does not work at all in recent versions. Defining odoo-specific environment variables to handle: - ODOO_REGISTRY_LRU_SIZE: the default registries size - ODOO_REGISTRY_LRU_SIZE_CRON: overwrite for cron workers Cron workers have often a different workload than HTTP workers and we may set a different limit there. If the limit is lower than the number of databases, a cron job will not reuse registries because it cycles through all known ones - in such cases, we can set a lower limit to keep the memory lower. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270069 Forward-Port-Of: odoo/odoo#268587
This update simplifies accessing employee profiles from the avatar card. Previously, a confirmation dialog forced users to activate inactive companies. Now, a 'View Profile' dropdown offers two options: directly opening the employee profile (activating the company) or accessing the contact profile without company activation. This provides a smoother user experience.
Original PR description
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the…
When opening a profile from the avatar card, the employee's company may not be in the user's active companies. Until now this popped a confirmation dialog that only let the user either activate the other company or cancel, with no way to reach the still-accessible contact profile. Replace the dialog with a less intrusive "View Profile" dropdown, shown only when the employee's company is allowed but not active. It offers two choices: - Open Employee Profile (activates the company) - Open Contact Profile (no company activation) Activating an extra company widens the active-company scope for the whole session, which is not always desirable, so keeping a non-mutating path to the contact profile is useful. In every other case (no employee, company already active, or company not allowed) the plain "View Profile" button is unchanged. task-6074597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270312 Forward-Port-Of: odoo/odoo#264073
This update prevents users who aren't designated approvers from directly accepting or rejecting approval requests through the activity interface. Previously, this caused errors when non-approvers attempted to interact with approval activities. This change improves system stability and ensures users only have access to actions relevant to their role.
Original PR description
Currently when a user submits an approval request, an activity is created for the approver who can validate or refuse the request directly from the activity, however these options are also visible to other users who will trigger an error if interacting with the options. This commit removes these options for users who are not the approver. **Steps to reproduce:** - Log in as admin - Go to approvals - Select dropdown menu of General Approval and Edit - Change documents to optionnal - Make sure admin is in the approvers list - Log in as demo - Go to approvals -> General Approval -> New Request - Submit the request - You'll see an activity be created for admin, with Accept and Refuse options - If you select any of these options you will get an access error opw-5423528 Forward-Port-Of: odoo/enterprise#120643 Forward-Port-Of: odoo/enterprise#109047
This update fixes a display issue where overtime details weren't showing correctly for employee attendance records. The team reversed a condition in the system's settings, ensuring that overtime information is now accurately presented for all attendance records, regardless of whether an employee has overtime rules configured.
Original PR description
Steps: * Create an extra-hours attendance for an employee that has overtime ruleset OR * Create an extra-hours attendance for an employee that has no overtime ruleset Issue: * The overtime details in the attendance view visibility condition was flipped Solution: * Reverse the visibility condition of the XML element Task: 6295710 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#269918 Forward-Port-Of: odoo/odoo#269744
This update resolves an issue preventing live chat visitors on mobile from adding emojis to their messages. The fix utilizes a technical solution to correctly identify clicks within the emoji picker, ensuring emojis are properly inserted into the composer. This improvement enhances the user experience for mobile live chat users.
Original PR description
Before this commit, livechat visitors couldn't use the "Add emojis" feature in composer when in mobile: this was opening the emoji picker, but when selecting an emoji this wouldn't add the emoji to the composer text. This happens because the livechat is inside a shadow DOM, and `ev.target` maps to livechat root rather than the specific click inside the emoji picker of livechat. This commit fixes the issue by using `ev.composedPath`, which goes through any open shadow DOM to find the most specific targets. The livechat is an open shadow DOM, thus this works like `ev.target` when there's no shadow DOM into play. This commit is also a follow-up of [1] where the file viewer was shown twice in website due to an accidental regression with fixing overlays: emoji picker was not working in desktop too, therefore the test also covers issues with the overlay like in [1]. [1]: https://github.com/odoo/odoo/pull/265603 Forward-Port-Of: odoo/odoo#267795
This update fixes an issue where the quantity received on a returned purchase order was incorrectly calculated. The change ensures that returns are accurately reflected in inventory, regardless of the return operation type. This prevents discrepancies in stock levels and improves the reliability of purchase order returns.
Original PR description
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Put your warehouse in delivery in 2 steps - On the receipt operation type change the return operation type to be "pick" by…
### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Put your warehouse in delivery in 2 steps - On the receipt operation type change the return operation type to be "pick" by default. - Create and confirm a PO for 1 unit of P - Validate the receipt > return > Create the return for 1 unit - Change the operation type of the return from Pick to Delivery to return the product in one step. - Validate the return #### > The qty_received is updated from 1 to 2 instead of 0. ### Cause of the issue: Updating the `picking_type_id` of the return will also update the `location_dest_id` to the default values: https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/stock/models/stock_picking.py#L1138-L1147 However, the default values of the `Delivery` is "Partner/customer". As such, the location dest of the move is also updated to be "Partner/customer". Now the issue is that the `qty_received` only considers moves to be returned if the location dest usage is not 'supplier': https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase/models/purchase_order_line.py#L226-L231 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L55-L67 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/purchase_order_line.py#L76-L77 https://github.com/odoo/odoo/blob/89807c10c20fb533124b18815f307fc3c380528d/addons/purchase_stock/models/stock_move.py#L129-L131 opw-6292918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269867
This update resolves an issue where errors during the forced payment process for cash drops would display confusing tracebacks to users. Now, errors are silently handled, preventing disruption. Additionally, a timeout has been added to Cashdro requests to quickly identify and address issues caused by incorrect IP addresses.
Original PR description
In odoo/odoo#268496, a fallback was added to automatically cancel the payment when forcing it, to avoid the cash machine getting stuck with a payment in progress. However, if an error occurs with this cancel request, it causes a traceback to appear. In this commit, we now catch the error from the cancellation, and don't show it to the user at all since they have already force completed the payment. We also add a timeout to Cashdro requests to fail faster when using a wrong IP (e.g. 1.2.3.4). task-6307491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270339
This update resolves a crash that occurred when adding reactions to messages on smaller screens. The fix ensures the correct data is passed to the reaction component, preventing errors and improving the user experience across different screen sizes. This enhancement ensures consistent functionality for all users.
Original PR description
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash: ``` Cannot destructure property…
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:
```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
at Proxy.onSelected
```
This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.
This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.
[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84
Forward-Port-Of: odoo/odoo#270158This update fixes an issue where capitalized email domains in alias settings caused emails to be misrouted. The change prevents users from saving capitalized domain names, ensuring emails are correctly delivered. This resolves a technical problem that could impact email delivery reliability.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257792This update resolves an issue where required fields on customer forms within the Point of Sale (POS) system were disappearing due to a change in how the form was displayed. The fix maintains the simplified view but uses an override mechanism to ensure localization modules can still add necessary fields, like those for invoicing. This ensures POS users can correctly manage customer data.
Original PR description
*: l10n_{ar,co,in,pe,uy}_pos **Problem:** The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the…
*: l10n_{ar,co,in,pe,uy}_pos
**Problem:**
The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS.
Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice.
**Solution:**
Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list).
Add a test to prevent future regression.
**Note:**
Another possibility is to re-inherit for each localization the new
standalone view, but this fix would need to update the module to work,
while this one works with just a restart.
There are still ongoing discussion with PoS team to see if we really
want to go back to each localization needing to inherit backend views.
[1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0bd77659b87359f2ca8763702462aaf92R26
opw-6244777 (many more)This update resolves an issue where required fields on the POS customer form were disappearing for various localization modules (BR, CL, EC, etc.). The fix maintains the simplified view but uses an override mechanism to ensure localization modules can still add necessary fields. This ensures accurate invoicing and customer data.
Original PR description
*: br,cl,ec,gt,it,ke,mx **Problem:** The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt…
*: br,cl,ec,gt,it,ke,mx **Problem:** The POS "Edit/Create customer" Form was switched to a standalone, hardcoded form view (view_partner_form_pos_ui) that inherits nothing during [1], in the attempt to simplify the view when accessed from the PoS. Every field that localizations and other modules add to the partner form by inheriting base.view_partner_form therefore disappeared when accessed from PoS. Some of the fields are required, for example, to invoice. **Solution:** Keep the simplified view as the default, but route the view selection through an overridable hook that localization can tweak case by case. The override is applied to the affected POS bridges (see module list). Add a test to prevent future regression. **Note:** Another possibility is to re-inherit for each localization the new standalone view, but this fix would need to update the module to work, while this one works with just a restart. There are still ongoing discussion with PoS team to see if we really want to go back to each localization needing to inherit backend views. [1]: https://github.com/odoo/odoo/pull/230721/changes#diff-66cd201e7e8cfff5218a9fa93efd72f0> opw-6244777 (many more)
A recent issue causing crashes in the Documents view when navigating from activities has been resolved. This fix addresses a technical problem related to how data is loaded asynchronously, preventing a 'TypeError' and ensuring the Documents view remains stable for users. This improves the overall reliability of the Documents feature.
Original PR description
### Description When navigating to Documents via an activity, the list view crashes with a TypeError on setting 'COMPANY'. ### Root Cause An asynchronous race condition occurs between parent and child `onWillStart` hooks. The child finishes an await before the parent's hook runs `expandDefaultValue()`. Thus, `this.state.expanded[sectionId]` is undefined when the child tries to write to its nested keys. ### Solution Await `sectionsPromise` first in the child hook. opw-6276003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#120713 Forward-Port-Of: odoo/enterprise#119634
This update resolves a bug preventing proper validation of rental transfers when using kit products. The system was incorrectly deleting and recreating stock moves, leading to errors. This fix ensures that rental transfers with kit products are processed correctly, improving the reliability of the rental process.
Original PR description
### Steps to reproduce: - Enable rental transfer - Create a rentable product R - Create and confirm a rental order for 1 unit of R - Create a kit bom for R: 1 x COMP - Validate the delivery of your…
### Steps to reproduce:
- Enable rental transfer
- Create a rentable product R
- Create and confirm a rental order for 1 unit of R
- Create a kit bom for R: 1 x COMP
- Validate the delivery of your unit of R
#### > Missing Error: Record does not exist or has been deleted.
### Cause of the issue:
Confirming your rental order will generate a confirm moves of R. However, since at this point the product was not a kit, these will not be exploded. Now, the issue is that at validation The move will be exploded and deleted in the super call:
https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L550-L555 https://github.com/odoo/odoo/blob/0f2f222a431627a672daf10c86ec2578a27f97bb/addons/mrp/models/stock_move.py#L591-L593 However, since the overrides of the sale_{mrp,stock}_renting modules call self rather than the result of the super call, they still expect to work with the original move rather than its exploded result: https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_mrp_renting/models/stock_move.py#L10-L13 https://github.com/odoo/enterprise/blob/7cceddaf086d849b8e2121e1023ef3479397534f/sale_stock_renting/models/stock_move.py#L61-L65
opw-6191841
Forward-Port-Of: odoo/enterprise#120793
Forward-Port-Of: odoo/enterprise#120051This update resolves a bug that prevented the Odoo upgrade command from functioning correctly when running in standalone mode. The fix addresses issues with argument persistence, redundant list splitting, and temporary paths interfering with standard library modules. This ensures the upgrade process works reliably for all Odoo deployments.
Original PR description
The command no longer works in standalone mode due to the following issues: - Each access to `self.parser` creates a new parser, so previously added arguments are lost. - The parsed `addons_path` value is already a list, but the command attempts to split it again. - The temporary Odoo paths remain in `sys.path`, causing Odoo modules to shadow standard library modules when running upgrade scripts. This commit addresses all the above issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269931
This update fixes a technical issue that prevented users from accessing the Time Off feature on mobile devices when logged in with specific user permissions. The fix ensures the system consistently returns expected data, preventing a traceback and improving the user experience. This resolves a minor bug impacting mobile users.
Original PR description
Steps to reproduce: 1. Access the database from a mobile device (or a small browser window) 2. Sign in as a user who has access to the Time Off module, but doesn't have an employee record 3. Open Time Off 4. Observe the traceback When we try to access Time Off with a user who has no employee record, we get a traceback due to receiving an empty dictionary from the backend. The error occurs because we try to iterate over this dictionary, even though we normally expect an array from the request we make. This commit will ensure we always return an array to the frontend, preventing the error. [opw-6295568](https://www.odoo.com/odoo/project/49/tasks/6295568?debug=assets)
This update fixes several visual issues within the spreadsheet component for the 19.2 release. Specifically, it addresses problems with dark mode display, tooltip readability, and the appearance of pivot table icons. These changes improve the user experience and ensure consistent functionality across different themes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c5c6fd3c81 [REL] 19.2.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/c5c6fd3c81 [REL] 19.2.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e8f060e58e [FIX] Headers overlay: unhide headers in dark mode [Task: 6233467](https://www.odoo.com/odoo/2328/tasks/6233467) https://github.com/odoo/o-spreadsheet/commit/0de087b7be [FIX] autofill: make tooltip readable in dark mode [Task: 6289977](https://www.odoo.com/odoo/2328/tasks/6289977) https://github.com/odoo/o-spreadsheet/commit/bb6868a517 [FIX] pivot: hide collapse icon when displaying formulas [Task: 6218524](https://www.odoo.com/odoo/2328/tasks/6218524) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update significantly speeds up inventory adjustments when processing large delivery orders with reserved packages. Previously, adjustments were slow and could freeze the user interface. The fix eliminates redundant database checks, resulting in a smoother and more responsive warehouse experience.
Original PR description
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse…
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts. Behavior after: Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation. Root Cause: When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing. Fix: Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries. Steps to Reproduce: 1. Have a product tracked by Lot and Package. 2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line. 3. Go to Inventory → Physical Inventory. 4. Set the counted quantity of any reserved bag to 0. 5. Click Apply. 6. Observe that the system takes time to process this single change. 7. Unreserve the delivery order. 8. Perform the same steps as mentioned above. 9. Inventory adjustment is much faster. opw-6234885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270228
This update resolves an issue where the website's recruitment search function couldn't find refused applicants. The previous change restricted searches to active refused applications, but refused applications are automatically archived. This fix ensures that refused applicants are now correctly searchable.
Original PR description
Searching on `[("application_status", "=", "refused")]` is always empty. It is an overlook from [odoo/206645] ([b6e4817]), where the `_search` query was changed to search only active refused applications. However, refused applications are always archived.
This was breaking `website_hr_recruitment` which was searching for refused applications, without finding any.
[odoo/206645]: https://github.com/odoo/odoo/pull/206645
[b6e4817]: https://github.com/odoo/odoo/commit/b6e48176219b2b123bcbf0353b8586c888fc6a94
opw-6204868
Forward-Port-Of: odoo/odoo#266370This update resolves an issue where multiple Oboxes connected to a database wouldn't all display a green Websocket status in the Kanban view. Now, all connected Oboxes show the correct status, ensuring accurate monitoring of Obox connectivity. This improves the reliability of Obox data visibility.
Original PR description
Before this commit, if you had multiple Oboxes connected to a DB, and you looked at them in the Kanban view, only 1 Obox would show a green status for Websocket, despite all of them being connected. After this commit, the Websocket status for each Obox is green as expected. Forward-Port-Of: odoo/enterprise#120828
This update fixes a discrepancy in the start dates of semi-monthly payrolls. Previously, payslips were incorrectly aligned with the month's halves, leading to inaccurate reporting. The change now ensures payslips begin on the 16th of the month, accurately reflecting the payroll schedule.
Original PR description
Issue: ---------------------------------------- The start date of semi-monthly payslips on second half of the month is the 15 which is also the end date of the first half of the month. Steps to reproduce: ---------------------------------------- - Have an employee with a semi-monthly payroll - When in the first half of the month, create a payslip for this employee - The payslip is from 1st to 15th - Do the same when in the second half of the month - The payslip is from 15th to end of the month Cause: ---------------------------------------- In `_schedule_period_start()` we set the start date to th 15th for semi-monthly payslips. Solution: ---------------------------------------- Set it to the 16th. opw-6281556 Forward-Port-Of: odoo/enterprise#120172
This update fixes an issue where Peppol invoices generated for certain customer types were missing the correct buyer reference information. The change ensures that the customer's Leitweg-ID is properly included in the XML invoice file, which is crucial for compliance with German regulations and Peppol standards. This resolves a problem preventing invoices from being correctly transmitted.
Original PR description
**Steps to reproduce:** - Install the `l10n_de` module and switch to a `DE Company`. - Enable `Peppol` in the Invoicing app settings. - Open the `DE Company` customer record. - In the `Invoicing`…
**Steps to reproduce:** - Install the `l10n_de` module and switch to a `DE Company`. - Enable `Peppol` in the Invoicing app settings. - Open the `DE Company` customer record. - In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`). - In the `Contacts & Addresses` tab, create an invoice-type contact named `test`. - Create a new invoice using the `test` contact. - Send the invoice via Peppol. - Download the generated `XML` and inspect the `BuyerReference` field. **Observation:** The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`. **Root Cause:** At [1], the `BuyerReference` node is populated using `vals['customer']`. For invoices addressed to an invoice-type contact, the contact itself does not contain the Peppol configuration, which is stored on the commercial partner. As a result, the code fails to retrieve the customer's `Leitweg-ID` and leaves the `BuyerReference` field empty. **Fix:** This commit ensures that the configured Leitweg-ID is correctly added to the `BuyerReference` field for child contact. [1]: https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97 opw-6269478 Forward-Port-Of: odoo/odoo#270459 Forward-Port-Of: odoo/odoo#269818
This update resolves an issue where the EC List XML export was incorrectly identifying partners with the same VAT number as separate entities, leading to rejection by tax agencies. The fix ensures that invoices with matching VATs are treated as a single partner, resolving the rejection and improving compliance with Belgian tax regulations. This change impacts the l10n_be reports module.
Original PR description
With l10n_be: - Create two contacts with the same VAT - Create an invoice for each that is EC List compatible - Generate the return and export the EC List XML In the generated xml the two partners with the same vat are treated as different partners, which causes a rejection by the tax agency. opw-6109585 Forward-Port-Of: odoo/enterprise#119729 Forward-Port-Of: odoo/enterprise#117702
Code cleanup and technical improvements
This update streamlines the account module's code by creating reusable JavaScript classes and removing unnecessary conditional statements. These changes enhance the system's efficiency and stability, ensuring consistent behavior across different account processes.
Original PR description
Made some generic JS classes that can be used between account move and account bank statement and removed some if statements that are no longer needed from account_tree controller because they were used to bypass default behavior if used by a model other than the intended one. This issue was fixed in: https://github.com/odoo/enterprise/pull/117476 task-5892419 Forward-Port-Of: odoo/odoo#264775
This update streamlines the bank statement import process by replacing a duplicated controller with a more efficient, generic version. Removing unnecessary code from the import module ensures accurate data processing and avoids potential conflicts with other Odoo modules, leading to a more stable and reliable import experience.
Original PR description
account_bank_statement_import_view was using the same controller used in account.move which caused some wrong behavior when some logic isn't shared between both modules, now account_bank_statement_import uses a generic controller that doesn't add unneeded behavior. As well as removing all of the account move classes from bank statement import and using generic ones or ones specific to account bank statement import. task-5892419 Forward-Port-Of: odoo/enterprise#117476
12 changes
Enhancements to existing features
This change addresses a requirement from Avalara, who need the LC116 code to be dotted for their city web services. Previously, Odoo automatically removed these dots. Now, the LC116 code is sent with the dots, allowing Avalara's tool to correctly sanitize the data.
Original PR description
Purpose: Avalara requires the LC116 code to be dotted for certain city webservices. Their tool will automatically sanitize the dots for cities that don't support it. Current Behavior: Odoo sanitizes the LC116 code before sending the JSON payload. Expected Behavior: The LC116 code is sent in the JSON payload with the dots. task-6304351 Forward-Port-Of: odoo/enterprise#120648
Resolved issues and error corrections
This update fixes an issue where errors during payment cancellation would display a traceback to users. Now, errors are handled silently, ensuring a smoother payment experience. Additionally, a timeout has been added to Cashdro requests to quickly identify and address problems caused by incorrect IP addresses.
Original PR description
In odoo/odoo#268496, a fallback was added to automatically cancel the payment when forcing it, to avoid the cash machine getting stuck with a payment in progress. However, if an error occurs with this cancel request, it causes a traceback to appear. In this commit, we now catch the error from the cancellation, and don't show it to the user at all since they have already force completed the payment. We also add a timeout to Cashdro requests to fail faster when using a wrong IP (e.g. 1.2.3.4). task-6307491 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270339
A recent issue causing the Documents view to crash when accessed through an activity has been resolved. This was due to a timing problem with how different parts of the system were updating data, leading to an error. This fix ensures the Documents view is stable and reliable for all users.
Original PR description
### Description When navigating to Documents via an activity, the list view crashes with a TypeError on setting 'COMPANY'. ### Root Cause An asynchronous race condition occurs between parent and child `onWillStart` hooks. The child finishes an await before the parent's hook runs `expandDefaultValue()`. Thus, `this.state.expanded[sectionId]` is undefined when the child tries to write to its nested keys. ### Solution Await `sectionsPromise` first in the child hook. opw-6276003 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#120713 Forward-Port-Of: odoo/enterprise#119634
This update resolves a crash that occurred when adding reactions to messages on smaller screens. The fix ensures the correct action object is passed, preventing errors and improving the user experience across different device sizes. This enhances the usability of the messaging feature for all users.
Original PR description
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash: ``` Cannot destructure property…
Before this commit, when browser window is small while not on a mobile device, clicking on the message action "Add a reaction" would lead to the following crash:
```
Cannot destructure property 'owner' of 'undefined' as it is undefined.
at Proxy.onSelected
```
This happens because cliking on this button on small screen would immediately trigger the complete showing of the emoji picker rather than just the quick menu. While this calls `action.onSelected()` and is expected to work [1], the problem is that this was passing the action definition rather than the action object as prop. As a result, `onSelected()` was using the definition and didn't pass the expected params that are destructed in the definition.
This commit fixes the issue by passing the `action` object to `QuickReactionMenu` component, so that the `action.onSelected()` is properly passing the `action.params`.
[1]: https://github.com/odoo/odoo/blob/19.0/addons/mail/static/src/core/common/quick_reaction_menu.js#L84
Forward-Port-Of: odoo/odoo#270158This update fixes an issue where capitalized email domains in aliases caused emails to fail to route correctly. The change prevents users from saving capitalized domain names, ensuring consistent email routing within the system. This resolves a technical problem that could have impacted email delivery.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257792This update resolves a technical problem preventing the Odoo upgrade command from functioning correctly when running Odoo in standalone mode. The fix addresses issues with argument persistence, redundant list splitting, and temporary path conflicts, ensuring the upgrade process works reliably.
Original PR description
The command no longer works in standalone mode due to the following issues: - Each access to `self.parser` creates a new parser, so previously added arguments are lost. - The parsed `addons_path` value is already a list, but the command attempts to split it again. - The temporary Odoo paths remain in `sys.path`, causing Odoo modules to shadow standard library modules when running upgrade scripts. This commit addresses all the above issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269931
This update significantly speeds up inventory adjustments when processing large delivery orders with reserved packages. Previously, adjustments were slow and could freeze the user interface. Now, inventory adjustments are much faster and more responsive, improving warehouse efficiency.
Original PR description
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse…
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts. Behavior after: Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation. Root Cause: When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing. Fix: Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries. Steps to Reproduce: 1. Have a product tracked by Lot and Package. 2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line. 3. Go to Inventory → Physical Inventory. 4. Set the counted quantity of any reserved bag to 0. 5. Click Apply. 6. Observe that the system takes time to process this single change. 7. Unreserve the delivery order. 8. Perform the same steps as mentioned above. 9. Inventory adjustment is much faster. opw-6234885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270228
This update fixes several issues within the Odoo spreadsheet component, improving its functionality and appearance. It includes enhancements to the autofill feature, pivot table display, and overall stability, ensuring a smoother user experience. These changes were made by a team of developers to maintain the quality and performance of the spreadsheet tool.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/53aa85b47b [REL] 19.1.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/53aa85b47b [REL] 19.1.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d1870b5369 [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132) https://github.com/odoo/o-spreadsheet/commit/53779bdaf5 [FIX] autofill: make tooltip readable in dark mode [Task: 6289977](https://www.odoo.com/odoo/2328/tasks/6289977) https://github.com/odoo/o-spreadsheet/commit/96278234b6 [FIX] pivot: hide collapse icon when displaying formulas [Task: 6218524](https://www.odoo.com/odoo/2328/tasks/6218524) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent update to our Weblate translation system unexpectedly reverted some code changes. This pull request has restored the original code, ensuring that updates to Weblate don't disrupt ongoing development. This is a minor issue being addressed to maintain stability.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit ec0cc1bfa31104d5880084c4e2db6e7822cd024a.
This update fixes a scheduling issue with semi-monthly payrolls in the second half of the month. Previously, payslips started on the 15th, coinciding with the end of the first half. Now, payslips begin on the 16th, ensuring accurate payroll calculations for employees on this schedule. This ensures consistent and correct payroll processing.
Original PR description
Issue: ---------------------------------------- The start date of semi-monthly payslips on second half of the month is the 15 which is also the end date of the first half of the month. Steps to reproduce: ---------------------------------------- - Have an employee with a semi-monthly payroll - When in the first half of the month, create a payslip for this employee - The payslip is from 1st to 15th - Do the same when in the second half of the month - The payslip is from 15th to end of the month Cause: ---------------------------------------- In `_schedule_period_start()` we set the start date to th 15th for semi-monthly payslips. Solution: ---------------------------------------- Set it to the 16th. opw-6281556 Forward-Port-Of: odoo/enterprise#120172
This update fixes an issue where Peppol invoices generated for certain German companies were missing the correct buyer reference information. The change ensures that the customer's Leitweg-ID is properly included in the invoice XML, ensuring compliance with Peppol regulations. This improves the accuracy of invoice data sent via Peppol.
Original PR description
**Steps to reproduce:** - Install the `l10n_de` module and switch to a `DE Company`. - Enable `Peppol` in the Invoicing app settings. - Open the `DE Company` customer record. - In the `Invoicing`…
**Steps to reproduce:** - Install the `l10n_de` module and switch to a `DE Company`. - Enable `Peppol` in the Invoicing app settings. - Open the `DE Company` customer record. - In the `Invoicing` tab, change the Peppol ID code from `Germany VAT` to `Germany Leitweg-ID` and set a code (e.g., `13075957-K000-52`). - In the `Contacts & Addresses` tab, create an invoice-type contact named `test`. - Create a new invoice using the `test` contact. - Send the invoice via Peppol. - Download the generated `XML` and inspect the `BuyerReference` field. **Observation:** The `<cbc:BuyerReference>` field is set to `N/A` instead of the configured `Leitweg-ID`. **Root Cause:** At [1], the `BuyerReference` node is populated using `vals['customer']`. For invoices addressed to an invoice-type contact, the contact itself does not contain the Peppol configuration, which is stored on the commercial partner. As a result, the code fails to retrieve the customer's `Leitweg-ID` and leaves the `BuyerReference` field empty. **Fix:** This commit ensures that the configured Leitweg-ID is correctly added to the `BuyerReference` field for child contact. [1]: https://github.com/odoo/odoo/blob/281658e86971687656f3235ac1ff8afcb52f2908/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_xrechnung.py#L87-L97 opw-6269478 Forward-Port-Of: odoo/odoo#270459 Forward-Port-Of: odoo/odoo#269818
This update fixes two issues related to USPS shipping rates. First, it now displays the correct unit of measurement (inches) for package dimensions, resolving confusion for users. Second, it ensures that USPS rates are correctly calculated based on the selected service type, not just domestic or international.
Original PR description
FW Changes ----- Discovered an error by re-enabling the tests, `res.partner` doesn't have a `company_name` anymore, it has been replaced by `parent_name` in…
FW Changes ----- Discovered an error by re-enabling the tests, `res.partner` doesn't have a `company_name` anymore, it has been replaced by `parent_name` in [18a59cf](https://github.com/odoo/odoo/commit/18a59cf26f2d9400f76deec483f6ddab87da0c55). Issue ----- There are 2 issues with USPS rest: 1. USPS packagings do not have their size UOM displayed. This leads to confusion as users input in inches but the dimensions are treated as feet. 2. USPS returns the same rate regardless of the package type. Steps to reproduce ----- - Set USPS up - Open the Package Type form > go to its' Dimensions tab > Issue 1 - Set USPS up (domestic) - Select a `Domestic Rating Indicator` (eg LF - Flat Rate Box) - Create a SO with some product - Open the delivery widget and add a rate with USPS - Discard the changes - Go to the delivery method and change the rating (eg SP - Single Piece) - Go back to the SO - Open the delivery widget and add a rate with USPS > Issue 2, rate is the same as before Issue 1 ----- By default, there is no displayed UOM on the form because of https://github.com/odoo/odoo/blob/38c737c2a4cc29b48235a100cfa9d6152af73826/addons/stock_delivery/models/stock_package_type.py#L20-L33 We can change this behaviour for USPS specifically as done in Envia https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_envia/models/stock_package_type.py#L37-L46 Issue 2 ----- In `usps_rest_rate_shipment`, we request rates for every package of the delivery, which we receive as lists. We then iterate over the list to find the rate matching the `mail_class`. The problem is that this only filters over whether the delivery is domestic or international. We don't filter based on the actual service selected on the carrier (`usps_domestic_rating_indicator` for domestic and `usps_international_rating_indicator` for international). https://github.com/odoo/enterprise/blob/20cc61e69aa3f6a59de1e962b25ce11fa402bf22/delivery_usps_rest/models/delivery_usps.py#L224-L236 ----- Ticket: opw-6224918 Forward-Port-Of: odoo/enterprise#120594
3 changes
Resolved issues and error corrections
This update ensures that Philippine sales reports exported to XLSX files consistently maintain the correct order of partner VAT values and row sequence. Previously, the order was unpredictable, leading to potential discrepancies in exported data. This fix guarantees data integrity for reporting and reconciliation purposes.
Original PR description
Description of the issue this commit addresses: SLSP XLSX partner rows were emitted in a non-deterministic order, which made the PH sales/purchases export tests sometimes swap partner VAT values. --- Desired behavior after this commit is merged: This commit keeps the SLSP partner rows in a stable order so the XLSX export always matches the expected partner VAT and row sequence. --- runbot-[162182](https://runbot.odoo.com/odoo/error/162182) Forward-Port-Of: odoo/enterprise#120052
This update removes an unnecessary 'external' tag from a key delivery module, preventing errors from being caught only during nightly testing. This change improves the reliability of our Continuous Integration (CI) process by ensuring all tests are executed. A minor adjustment was also made to a test case to accurately reflect package weight calculations.
Original PR description
Test class was tagged as external although calls are mocked. This means errors were only caught in nightly and not by CI. Removing the tag requires fixing some of the tests. For `test_multicollo`, we send the average weight of packages instead of the total since 97f82442c9fee7dcb3e8c5e9bacddcd6bb864e11. Forward-Port-Of: odoo/enterprise#114660 Forward-Port-Of: odoo/enterprise#111660
This update adds a new test to verify the handling of fully settled customer invoices within the POS system. The previous fix related to tracking 'move' statuses has been incorporated into this test, ensuring continued accuracy in settlement calculations. This change improves the reliability of the POS settlement process.
Original PR description
Just keeping the test in this FW. The original issue was fixed in https://github.com/odoo/enterprise/pull/119084 opw-6173760 Forward-Port-Of: odoo/enterprise#116536
9 changes
Resolved issues and error corrections
This fix resolves an issue where extra prices were incorrectly applied to products with 'always' attributes when creating combos in Point of Sale. The update ensures that extra prices are now set on the combo creation page for 'always' attributes, aligning with the intended functionality and preventing double-counting.
Original PR description
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both…
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both those attributes - Create a combo with that product with both values for A - Go to the PoS and order that combo with the value that has an extra price for A - The extra price is added ## Why the fix: For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo. As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page. It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always". The variants are then considered as different products, as they should in this case. If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it. We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same. opw-6262431
This update corrects a visual issue where product images in the grid layout didn't display in the correct left-to-right order. The change adjusts how images are navigated within the product image viewer to match the user's visual perception, ensuring a consistent and intuitive shopping experience.
Original PR description
This commit ensures product images follow their visual order in the product image viewer when using the grid layout. Steps to reproduce: - Open a product page with multiple images (or add Extra Media…
This commit ensures product images follow their visual order in the product image viewer when using the grid layout. Steps to reproduce: - Open a product page with multiple images (or add Extra Media to the product) - Change layout mode to "Grid" and click save - Click any image to open the product image viewer - Navigate between images Images do not follow the visual left-to-right order. This regression was introduced by [commit], which replaced the row-based grid with a column-first layout. As a result, `querySelectorAll` returns images in DOM order, which no longer matches the visual order. To fix this, images are now reordered based on their visual placement in the grid so navigation matches the order seen by the user. Images are traversed in visual left-to-right order while also accounting for varying image heights and multi-column alignment. [commit]: https://github.com/odoo/odoo/commit/9a3628b9735550bf8ecc2252ea1b7338f68ab966 task-[4364143](https://www.odoo.com/odoo/project/974/tasks/4364143) Forward-Port-Of: odoo/odoo#269855 Forward-Port-Of: odoo/odoo#254077
This update resolves an issue where navigating between tasks in Odoo caused errors due to outdated information being restored from the user's browser session. The fix ensures that only dynamic actions are reused, preventing errors related to invalid context data and improving overall task navigation stability. This enhances the user experience by eliminating unexpected application behavior.
Original PR description
Steps to reproduce: - Open any project task - Click a project notification that opens another task (requires the corresponding notification preference to be enabled) - Use the browser's Back and Forward buttons => Traceback: active_id is undefined When navigating to a form view via a URL (e.g. `/odoo/m-<model>/<id>`), the action service looks up the last action from session storage and reuses it if the model matches. This behavior, introduced in a4b179a7118916aac032ad252c0e421d452e553c, does not discriminate between dynamic and non-dynamic actions. Non-dynamic actions (those with an id) may rely on context values such as active_id that are only valid in their original execution context. Restoring such an action during browser history navigation causes a traceback because active_id is undefined. Fix by only reusing the session-stored action when it is a dynamic action (no id). Forward-Port-Of: odoo/odoo#270076
This update fixes an issue where capitalized email domains were causing routing problems. The change prevents users from saving capitalized domain names, ensuring emails are correctly processed and delivered. This resolves a technical limitation impacting email functionality.
Original PR description
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues Currently, we allow capitalization in the name / display_name field for Email Domains…
[FIX] mail_alias_domain: prevent capitalization in domain names to avoid email routing issues
Currently, we allow capitalization in the name / display_name field for Email Domains (mail.alias.domain), which allows for capitalized domains in email aliases. When the system receives incoming emails via mail_thread.py's message_route,
the reply_to email addresses are sanitized (all lowercase). We then use the case-sensitive 'in' to identify
message routes, which will always fail for capitalized email domains.
This PR applies sanitizing to the name field so that users cannot save capitalized email domains.
Other options are not viable because:
1. we don't have a case-insensitive equivalent of the 'in' operator
2. altering the current logic to be case-insensitive would decrease performance
3. altering the current logic would change the structure of message_route
Fixes #opw-5401633
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257792This update corrects an issue where the link editor unexpectedly appeared when creating multiple tracked links. The fix ensures the editor is properly canceled when a new link is generated, preventing confusing behavior and improving the user experience. This resolves a minor usability problem.
Original PR description
Steps to reproduce: - Go to the Link Tracker page - Generate a first tracked link - Click on the button to start editing the code - Click on "create another tracker" - Generate a second tracked link => When you access the screen to see/edit the tracked link url, the buttons "ok" and "cancel" are already present. Clicking on "ok" display a traceback. To fix this issue, this commit also cancels edition when clicking on "create another tracker". task-4531974 Forward-Port-Of: odoo/odoo#268573
This update fixes an issue where the number of comments displayed on course slides wasn't accurately reflecting the actual number of comments due to recent changes in how Odoo handles messages. The fix ensures that comment counts are synchronized with the current number of available comments, improving the user experience.
Original PR description
Steps to reproduce: - Open a slide of a course in non fullscreen mode (website). - Go to the comments tab and add a comment in the chatter. - The comments count does not change in the tab. - The same thing happens when a comment is deleted. - Another way to see the incorrect counter is to add a note in the slide form view (backend). Before this change, `website_slides` used `website_message_ids` to calculate the comments. Since #138233 the old portal chatter has been replaced with the mail chatter and the way messages are displayed on the portal has changed. For example notes are no longer considered portal messages and also deleted messages should not be displayed or counted as such. This change ensures that comments calculations are based on a domain that considers those changes meaning that comments will be synced with the actual number of available comments. Forward-Port-Of: odoo/odoo#263087 Forward-Port-Of: odoo/odoo#260376
This update fixes an issue where sales and purchase reports in the Philippines (SLSP) were sometimes exported with incorrect partner VAT values due to an unpredictable order of rows. The change ensures a consistent and reliable export, guaranteeing the correct partner VAT and row sequence for all reports. This improves data accuracy and reduces potential errors in financial reporting.
Original PR description
Description of the issue this commit addresses: SLSP XLSX partner rows were emitted in a non-deterministic order, which made the PH sales/purchases export tests sometimes swap partner VAT values. --- Desired behavior after this commit is merged: This commit keeps the SLSP partner rows in a stable order so the XLSX export always matches the expected partner VAT and row sequence. --- runbot-[162182](https://runbot.odoo.com/odoo/error/162182) Forward-Port-Of: odoo/enterprise#120052
This update significantly speeds up inventory adjustments when making changes to large delivery orders with reserved packages. Previously, adjustments were slow and could freeze the user interface. Now, inventory adjustments are much faster and more responsive, improving warehouse efficiency.
Original PR description
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse…
Behavior before: Adjusting physical inventory quantities for reserved packages takes time when linked to large delivery orders (e.g., 400+ lines). The user interface freezes, causing a poor warehouse user experience during stock counts. Behavior after: Inventory adjustments on reserved packages process faster. The UI remains responsive, and package records are updated instantly without performance degradation. Root Cause: When an inventory adjustment triggers '_free_reservation', it processes move lines sequentially. Inside this loop, Odoo recursively runs '_check_entire_pack()', forcing a full database evaluation of all 400+ delivery lines for every single line adjusted. This results in heavy, redundant processing. Fix: Used a context flag `bypass_entire_pack=True` to silence the '_check_entire_pack()' validation while looping through individual line adjustments. Once the loop completes, the package validation is called exactly once in batch for all affected pickings, preserving data integrity while eliminating redundant database queries. Steps to Reproduce: 1. Have a product tracked by Lot and Package. 2. Have an open delivery order in Ready state (stock reserved) containing 400 or more lines of this product, one package per line. 3. Go to Inventory → Physical Inventory. 4. Set the counted quantity of any reserved bag to 0. 5. Click Apply. 6. Observe that the system takes time to process this single change. 7. Unreserve the delivery order. 8. Perform the same steps as mentioned above. 9. Inventory adjustment is much faster. opw-6234885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270228
This update ensures the Odoo spreadsheet functionality is running the most recent version, addressing potential bugs and improving performance. It’s a routine maintenance task to keep our spreadsheet tools reliable and up-to-date. This change focuses on internal improvements to the spreadsheet component.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/233f3eafec [REL] 18.3.51 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3f01c9d938 [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
2 changes
Resolved issues and error corrections
This update resolves a bug that prevented receipts from printing correctly after the first order in the Italian POS module. The fix ensures that receipts are always printed via the payment screen, streamlining the process and eliminating printer deadlocks. The change also simplifies the user interface by hiding unnecessary settings for Italian fiscal printers.
Original PR description
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview…
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview Screen"; - Disable "ePos Printer"; - Set up an Italian Fiscal Printer; - Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required. Cause: When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of `renderService`, permanently blocking the printer queue. Solution: Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option. UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured. Community PR: https://github.com/odoo/odoo/pull/256932 [opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212) Forward-Port-Of: odoo/enterprise#112654
This update ensures that sales and purchase reports exported to XLSX in the Philippines (SLSP) consistently maintain the correct order of partner VAT values and row sequence. Previously, the order was unpredictable, leading to test failures. This fix guarantees reliable export data for reporting and compliance.
Original PR description
Description of the issue this commit addresses: SLSP XLSX partner rows were emitted in a non-deterministic order, which made the PH sales/purchases export tests sometimes swap partner VAT values. --- Desired behavior after this commit is merged: This commit keeps the SLSP partner rows in a stable order so the XLSX export always matches the expected partner VAT and row sequence. --- runbot-[162182](https://runbot.odoo.com/odoo/error/162182) Forward-Port-Of: odoo/enterprise#120052
8 changes
New functionality added to Odoo
This update adds crucial product information – like price, tax details, and supplier codes – to the data sent to Pricer. This enhancement enables more accurate pricing calculations for common sales scenarios. The update also ensures Pricer tags are automatically updated when related product information changes.
Original PR description
We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#120226 Forward-Port-Of: odoo/enterprise#78009
Enhancements to existing features
This update enhances the Odoo Enterprise payroll system by displaying a warning banner directly on the employee form. This allows payroll officers to quickly identify and address any missing or incorrect employee data, streamlining their workflow and improving data accuracy. The changes ensure payroll users receive critical alerts regarding pay runs and other relevant information.
Original PR description
To ensure Payroll officers can quickly identify missing or incorrect employee data, this commit extends the warning banner to the top of the Employee form view. Changes: - Extended `_compute_issues` in `hr_payroll` to safely append payroll-specific warnings (e.g., missing pay runs) without overwriting the base HR issues. - Leveraged the existing `actionable_warnings` widget in `hr_payroll` to handle the combined, multi-level warnings for payroll users. - Inherited the view in `hr_payroll` to dynamically replace the widget with `actionable_warnings` specifically for users in the `hr_payroll.group_hr_payroll_user` group. task-5118781
This update enhances the user experience by automatically displaying a paperclip icon on statement lines when supporting documents are attached. Additionally, the system now refreshes statement lines after document uploads, eliminating the need for manual page refreshes to view attachments. This streamlines the process of managing and accessing supporting documentation for financial statements.
Original PR description
Users can add supporting documents directly on a statement line. Make the statement line show a paperclip in this case. Also refresh the statement line after posting a log note because without that the attachments uploaded through a log note would require the user to refresh the page to show the paperclip. --------------------------------------------------------------------------------------------------------------------- Use the statement line attachment field when downloading attachments instead of searching the same attachments separately. task-6237923
This update simplifies the HR payroll configuration menu by renaming the 'Work Entries' section to 'Time Management'. This change enhances user experience and aligns with updated terminology within the Odoo Enterprise system. It follows up on a previous task to streamline the setup process.
Original PR description
This PR expected to rename 'Work Entries' in configuration menu to 'Time Management'. follow up from from previous task: 5976238. task: 6290162
This update enhances the working file exports by now including related checks alongside the trial balance. The changes add a new page for the checks, grouping them by cycle and displaying relevant notes, while also removing unnecessary account state information for a cleaner export.
Original PR description
Before the change when you export a working file, we print the trial balance filtered on the accounts audited during the considered period. Users however expect to also export the related checks. This change include the checks in the export, the first page is dedicated to the trial balance. The checks list start on a new page and the checks are grouped by cycle with the notes shown if there is an input. Also, the account states are removed from the pdf export. task: 6124865
Resolved issues and error corrections
A recent issue preventing the successful installation of demo data for the pos_restaurant_appointment module has been resolved. The fix corrects a coding error that was preventing the correct data loading process, ensuring demo data can now be properly installed.
Original PR description
Demo data installation failed because `_load_pos_self_data_read` was used instead of `_load_pos_data_read`. Use the correct loader to allow successful module installation. Runbot Error-940277
This update removes a misleading warning related to R&D time reporting, streamlining the payroll process for users in Belgium. Additionally, an unused field related to contract withholding taxes exemptions has been removed, simplifying data management. This change improves the accuracy of payroll reports and reduces potential confusion.
Original PR description
. Remove not needed Missing R&D Time Rate warning . Remove l10n_be_contract_withholding_taxes_exemption field task-6296840
This update corrects a duplication of the 'abstract field' feature that was previously introduced in the base Odoo module. The change removes an unnecessary override in the web_studio module, ensuring consistency across the Odoo platform. This streamlines development and avoids potential conflicts.
Original PR description
The abstract field was added in odoo/odoo#186121 in the base module. Removing the overwrite here.
2 changes
Resolved issues and error corrections
This update resolves a rejection issue with French VAT reports submitted to the DGFiP. The problem stemmed from incorrect 'millesime' (form version year) data, causing the 3519 reimbursement form to be flagged. By correctly deriving the millesime from the reporting period, the system now ensures accurate and accepted VAT reports.
Original PR description
The 3519 reimbursement form is rejected by the DGFiP with "Le millesime 25 du formulaire 3519 est inconnu dans la teleprocedure TVA". The 3310CA3 return is still accepted, because its layout is unchanged year-on-year, which hides the problem, but it is sent with a millesime that no longer matches the campaign. The millesime is the form-version year. The EDI-TVA 2026 campaign opened on 2026-02-09. last update: https://github.com/odoo/enterprise/pull/92542 opw-6275695
This update resolves an issue preventing users from archiving multiple Point of Sale (POS) configurations simultaneously. The original code had a technical error related to how it handled field types, causing a validation error when attempting to archive multiple POS setups. The fix utilizes a more robust method to handle data, ensuring correct archiving functionality for all POS configurations.
Original PR description
Step to reproduce: - install `l10n_be_pos_blackbox` with demo data - go to pos → configurations → point of sales - select 2 or more configs and try to archive Observation: - Traceback ``` File…
Step to reproduce:
- install `l10n_be_pos_blackbox` with demo data
- go to pos → configurations → point of sales
- select 2 or more configs and try to archive
Observation:
- Traceback
```
File "/19.0/l10n_be_pos_blackbox/models/pos_config.py", line 73, in write
if (vals.get('l10n_be_blackbox_be_id') or self.l10n_be_pos_id):
^^^^^^^^^^^^^^^^^^^
File "/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: pos.config(3, 4, 5)
```
Cause:
- it looks like `l10n_be_pos_id` is a m2o field and `self.l10n_be_pos_id` should
work for multiple records, but `l10n_be_pos_id` is a char fields and hence
this is not resolved and we get error
https://github.com/odoo/enterprise/blob/42e438b1366f48addbe826f363952d3261467c33/l10n_be_pos_blackbox/models/pos_config.py#L20-L26
Fix:
- use `mapped` to check values in multiple records
opw-63057695 changes
Resolved issues and error corrections
This update resolves an issue preventing users with appropriate Sale access from inserting data into Quotation templates through the spreadsheet management feature. The change adds a setting to ensure the necessary flag is activated when the module is installed and the user has the correct permissions, streamlining the process.
Original PR description
Current behavior before PR: - The `can_insert_in_spreadsheet` session flag was not set by the spreadsheet_sale_management module. - Users with proper Sale access rights still could not insert into Quotation templates. Desired behavior after PR is merged: - Added logic to set `can_insert_in_spreadsheet` when the module is installed and the user has the required access rights. Task: [5960761](https://www.odoo.com/odoo/project/2328/tasks/5960761)
This update addresses a bug fix within the Odoo spreadsheet component. Specifically, it resolves an issue with finding and replacing text selections after cell updates, ensuring data integrity within spreadsheets. This change improves the reliability of spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/18d4601b09 [REL] 18.0.71 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e4e0c90ddc [FIX] Find and replace : selection after an UPDATE_CELL [Task: 4818132](https://www.odoo.com/odoo/2328/tasks/4818132) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
A recent update to our Weblate translation system unexpectedly reverted some code changes. This pull request corrects this issue by restoring the original code. This ensures that future translation updates don't unintentionally disrupt existing functionality.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit 6cce5fdde972634cdceb4ff573c0f9b67297cd1f.
This update corrects a visual bug where the 'jump to present' button appeared incorrectly when the chat window was hidden behind a long form. The fix ensures the button is only visible when the thread itself is visible, preventing a confusing flicker and ensuring the button functions as intended.
Original PR description
### Description `Thread.updateShowJumpPresent()` (`addons/mail/static/src/core/common/thread.js`) sets `showJumpPresent` from the present-sentinel visibility only, without checking that the thread…
### Description
`Thread.updateShowJumpPresent()` (`addons/mail/static/src/core/common/thread.js`) sets `showJumpPresent` from the present-sentinel visibility only, without checking that the thread itself is on screen:
```js
this.state.showJumpPresent =
this.props.thread.loadNewer || this.presentThresholdState.isVisible === false;
```
In a form chatter, when the user is at the **top of a long form**, the whole chatter is below the fold. The present sentinel is therefore not visible, so the `position-fixed` jump-to-present button shows up even though the thread is off-screen — and clicking it does nothing useful (the scrollbar flickers, no jump).
### Fix
Gate `showJumpPresent` on the thread's own visibility (`this.visibleState`), exactly as on **saas-18.3+/19.0/master**. The 18.0 port of the jump-to-present rework (460d066817, #246299) brought the threshold/position changes but dropped this guard, so 18.0 (and saas-18.2) are still affected.
### Steps to reproduce (standard, runbot)
1. Open a record with a chatter and a long form (e.g. a CRM lead / Sales order).
2. Scroll to the **top** of the form (chatter below the fold).
3. The round jump-to-present button appears at the bottom; clicking it does nothing.
With this patch the button is hidden while the thread is off-screen, matching saas-18.3+.
<img width="5152" height="1926" alt="84359" src="https://github.com/user-attachments/assets/a16dbb74-c5c4-440a-8a94-ec7c5693904e" />This update resolves a problem where the automated tour for restaurant order placement would sometimes fail due to asynchronous communication with the kitchen. By adding a brief delay, the tour now ensures all order requests are fully processed before proceeding, preventing duplicate requests and improving the reliability of the test.
Original PR description
The tour could fail because `sendOrderInPreparationUpdateLastChange` is asynchronous when sending the order to the kitchen. The test was continuing to the next steps before the request was fully resolved, which could lead to sending the order again while the previous call was still in progress. This commit updates the tour to explicitly wait for the async call to complete before continuing, by adding a delay step after clicking the order button. This prevents race conditions during the test. --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/181846 Forward-Port-Of: odoo/enterprise#110909
7 changes
Resolved issues and error corrections
This update resolves a visual inconsistency in email attachments. Previously, buttons with long text labels would render incorrectly in email clients like Gmail, causing text to wrap around the button background instead of maintaining a single box. The change ensures buttons with long text labels display correctly in emails, matching the preview in the editor.
Original PR description
The mail CSS inliner drops every declaration whose name or value contains "flex" because Windows Outlook has no flexbox support. A button styled display:inline-flex therefore loses its display along…
The mail CSS inliner drops every declaration whose name or value contains "flex" because Windows Outlook has no flexbox support. A button styled display:inline-flex therefore loses its display along with the genuine flex declarations. Mail clients fall back to the default display:inline of the <a>, so a button whose label wraps over several lines paints its background, padding and radius around each line of text instead of around the whole box, even though the editor preview still shows a single box. classToStyle and _getMatchedCSSRules in convert_inline.js now map display:inline-flex to inline-block instead of removing it. inline-block is supported across mail clients and keeps an inline element rendered as a single box. The other flex declarations are still removed. Before: <img width="767" height="358" alt="image" src="https://github.com/user-attachments/assets/04ecda63-3041-4e81-888d-744a168ee4d2" /> After: <img width="692" height="457" alt="image" src="https://github.com/user-attachments/assets/4c733885-6124-4b04-b339-00aa9a8e4465" /> Steps to reproduce: 1. In Email Marketing, create a mailing and add a button with a label long enough to wrap over two lines. 2. Open the code view and set the button style to display: inline-flex. 3. Send a test of the mailing and open it in a webmail client such as Gmail. => the button background wraps each line of text instead of forming a single box Ticket [link](https://www.odoo.com/odoo/project.task/6234435) opw-6234435
This update fixes an error in the Italian localization module that caused incorrect DDT (Delivery Deduction Tax) pricing when products were delivered across multiple lots. The fix ensures that the total sale price of all lots is accurately reflected in the DDT cost calculation, preventing overcharging. This improves the accuracy of tax reporting for Italian customers.
Original PR description
Steps to reproduce: 1. Install Italian localization and l10n_it_stock_ddt 2. Create a product tracked by lots with a price of 100 3. Create two lots for that product, each with 5 in stock 4. Create a sale order for a quantity of 8 5. Confirm the sale order and validate the delivery 6. Print the delivery note Issue: Only the first lot's sale price is used in the DDT cost calculation (price = 500 instead of 800) Why this happens: The QWeb template used `move.move_line_ids[0].sale_price`, which only reads the sale_price of the first move line. When a delivery is split across multiple lots, each lot produces its own move line, so only the first is considered in the price calculation. opw-6244076
A recent update to our Weblate translation system unexpectedly reverted some code changes. This pull request is correcting this issue by restoring the previous state of the affected modules. This ensures that our translation workflows continue to function as designed.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit 4894b95a7913fcf8f059b3ec6dbf3d3f5140d62c.
A recent update to our Weblate translation system incorrectly reverted some code changes. This pull request has been implemented to restore the original code, ensuring that future updates don't cause unintended disruptions. This is a minor correction to maintain the stability of our translation workflows.
Original PR description
The regular Weblate translation update reverted some code changes. This should normally not happen. We're reverting it back to the previous state. This partially reverts commit bc761f350e309e84ed95527ea7ef901c156c06ee.
This update resolves a bug in the account reports that prevented correct hierarchical totals in comparison reports. Specifically, a numerical issue caused totals to reset to 'None', leading to missing intermediate totals. This ensures accurate reporting and comparison of financial data.
Original PR description
In some cases, in `compute_group_totals`, `column.get('no_format')` is not a float but an int (`0`). This will reset the total to `None`.
**Steps to reproduce:**
1. Install `l10n_be` to have demo datas and use the demo belgium company.
2. Create an invoice in current year, with a line on the account Sale for Export.
3. Create an invoice in previous year, with a line on the account Sale in Belgium.
4. Open the account report Profit and Loss, enable the comparison with 1 previous period, and check the option Hierarchy and Subtotals.
5. In the previous year column, there is no intermediate total in the hierarchy
Ticket [link](https://www.odoo.com/odoo/project.task/6269004)
opw-6269004This update corrects a technical issue within the Odoo's Danish accounting module (l10n_dk) where an account was listed twice. Removing this duplication ensures accurate financial reporting and avoids potential errors. This change improves the reliability of the accounting data.
Original PR description
In the list 'dk_coa_7630 ', the account has been used in the list twice. Removing the duplication from the list. [Reference](https://github.com/odoo/odoo/blob/17.0/addons/l10n_dk/migrations/1.4/end-migrate.py#L14) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows binary files uploaded through forms to store their filenames, resolving an issue that previously caused incorrect file type detection. This change is important for seamless file uploads and proper functionality, especially for Odoo SaaS modules and future migrations.
Original PR description
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual…
Description of the issue/feature this PR addresses: Since [1], studio binary fields uploaded through a form store their filename. Due to the condition of [1], this behaviour is restricted to manual fields, which limits the usage of those fields in standard and is particularly problematic when Saas modules that use this feature are migrated to Python. Not storing the filename can lead to incorrect mimetype guesses. Given that a more appropriate condition has already been added in [2], it should no longer be necessary to restrict this feature to manual fields. This commit removes that restriction to allow standard binary fields to store their filename when uploaded through a form. Current behavior before PR: When uploading a file to a non-manual binary field that has a related '_filename' field, the filename will not be stored, which can later lead to incorrectly guessing the mimetype of the file. Desired behavior after PR is merged: Uploading a file to a non-manual binary field that has a related '_filename' field stores the filename of the file. Task related to this issue: https://www.odoo.com/odoo/project.task/5917543 [1] https://github.com/odoo/odoo/commit/0e2f3b144581c47d25a99cecdd7e058a3d55bcc3 [2] https://github.com/odoo/odoo/commit/1bcab2f42eebf98127416e54f31cd6e351938b7f --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr