Daily updates from Odoo
Monday, April 27, 2026
275 changes
6 changes
Resolved issues and error corrections
This update resolves an issue where users migrating to the ESG module experienced problems due to an automatic installation of a related dependency (survey). By adding survey as a required auto-install, the system now only installs survey when users already have the necessary data, preventing migration disruptions and ensuring a smoother upgrade process.
Original PR description
Description of the issue this commit addresses: As survey is a dependency but not an auto_install requirement of esg_csrd only from 19.0, when migrating to that version, users that don't have survey installed but do have esg will auto_install survey and pull a new computed stored field, ResUsers.karma which causes migrations issues as no script was made to account for that scenario. --- Desired behavior after this commit is merged: This commit adds survey in the auto_install requirements for the module so only instances that already have ResUsers.karma can auto_install esg_csrd --- runbot-238524 Forward-Port-Of: odoo/enterprise#113905
This update ensures that payrun steps are correctly marked as 'valid' when the user proceeds after encountering an error. Previously, errors could linger, making it appear that key data wasn't processed. This change provides a more reliable indication of payrun completion, improving data accuracy.
Original PR description
Before: - Clicking Continue moved the payrun to the next step, but the previous step could remain in `error` if anomalies were still present. - This made explicitly passed steps (version/time/attendance) look unresolved. After: - Continue marks the passed step as `valid`. - because if the user willfully ignore an error, then it's ok to put it as validated. - This is applied consistently for all payrun step state points. Task-6053982
This update resolves an issue preventing the creation of webhooks for companies with non-alphanumeric characters in their names. The fix utilizes a regular expression to sanitize webhook names, ensuring compatibility and allowing authorized users to successfully set up webhooks for the payment process. This improves the reliability of the payment authorization feature.
Original PR description
Issue: --- Due to this issue, if the company name has non-alphanumeric chars, `authorize` doesn't allow us to create a webhook. ### Steps to reproduce: 1- Create a company with a non-alphanumeric char (_ is allowed so something else such as `company - 1`) 2- Setup `Authorize` payment. 3- Generate webhook. Fix: --- We can remove it using regular expression. `\w` matches characters from a to Z, digits from 0-9, and the underscore `_` character. https://www.w3schools.com/python/python_regex.asp#:~:text=%5Cw,%2C%20and%20the%20underscore%20_%20character opw-6152999
This update fixes an issue where profit and loss accounts were incorrectly appearing in balance sheet reports. The change prevents grouping at the report level, ensuring that balance sheets only display the intended asset and liability information. This improves the accuracy and reliability of financial reporting.
Original PR description
…er unfolded Since the groupby at report level, lines such as "Current Year Unallocated Earnings" were displaying profit and loss accounts in the balance sheet, which is not a desired behavior. task-6152675
Features or functions removed from Odoo
This update addresses a technical detail within Odoo's email server configuration. The 'max_email_size' field in the ir.mail_server module is now marked as deprecated, signaling its removal in a future version. This change ensures compatibility with upcoming updates and streamlines the email server setup process.
Original PR description
In odoo/odoo#256685, we remove the use of ir.mail_server max_email_size field by making the method _get_max_email_size only rely on the ICP parameter and not any more on that field. As we were too late to remove the field in 19.3, we add a comment to indicate that the field is deprecated and will be removed in 19.4. Task-5912830
This update improves how Odoo stores composer data, moving from using browser storage (localStorage) to a more secure and efficient method called IndexedDB. This change enhances performance and stability of the composer feature within Odoo.
Original PR description
This PR removes the use of localStorage to store composer in favor of IndexedDB. task-5905857
23 changes
Enhancements to existing features
This update enhances the reporting features within the Enterprise edition by making return type menu options consistently available, regardless of whether debug mode is enabled. This change expands user access to critical reporting configurations, streamlining the process for financial analysis and reporting.
Original PR description
Before, the menu return types in configuration was only available in debug mode. Now it is available for the group `account.group_account_readonly` task-5912751 Forward-Port-Of: odoo/enterprise#114830
Resolved issues and error corrections
A minor bug preventing users from clocking in with a blackbox POS terminal has been resolved. The fix corrects a typo that was causing an error in how receipt data was generated, ensuring proper functionality.
Original PR description
There is a typo trying to assign the server version to `this` instead of the `data` object which is used for the receipt. This causes a `cannot set properties of undefined` error when trying to clock in with a blackbox
This update fixes a display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, providing a clearer and more intuitive representation of performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where CFDI generation for payroll payslips failed due to rounding discrepancies between the company's currency settings and the XML formatting requirements. The fix explicitly rounds payroll amounts to 2 decimal places, ensuring compliance with CFDI standards and preventing errors.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update fixes an issue where MyInvois consolidation documents incorrectly combined invoices with gaps in their sequence numbers. The change now accurately splits the batch into multiple XML lines when invoices are missing, ensuring correct invoice generation and reducing potential errors. This improves the reliability of the MyInvois document creation process.
Original PR description
When generating a consolidated MyInvois document, the system must split the batch into multiple XML lines if there are gaps in the sequence (e.g., if an invoice in the middle of the range was already sent individually) The previous logic attempted to detect these gaps by searching the database(`account.move`) for any invoices that fell within the sequence range and lacked a EDI document. Because this search would find the "missing" invoices, it would fill the gap and fail to detect it and produce a single consolidated line. This commit replaces the search and relies only on the selected recordset, along with the addition of sorted `sequence_number` for gap detection and adds test for handling consolidation of broken sequences. Task: [6057214](https://www.odoo.com/odoo/project.task/6057214) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261150
This update fixes an issue where IoT events were missed due to a failure in the longpolling fallback mechanism. Now, if longpolling fails, the system automatically switches to websocket, ensuring that critical events, such as Worldline payment confirmations, are reliably received. This improves the stability and functionality of our IoT integrations.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/260931 Before this commit, if `onMessage` in `iot_http_service` was called directly, it would fail to fallback to websocket if the longpolling request failed, causing events to be missed. One symptom of this is Worldline payments failing to confirm when using websocket. After this commit, the `_longpolling` method will now throw an error in this case, causing the fallback mechanism to attempt websocket instead. Forward-Port-Of: odoo/enterprise#114882 Forward-Port-Of: odoo/enterprise#114779
This update corrects a visual issue where adding a new shift could duplicate employee names in Gantt views. The fix ensures that employee display updates correctly, preventing the display of the same employee multiple times. This improves the user experience and data accuracy within the Gantt view.
Original PR description
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An…
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have: ``` +--------------+ | Shift1 User1 | +--------------+ ``` Add another shift (Shift 2) with User2. We'll have: ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User1 | +--------------+ ``` instead of ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User2 | +--------------+ ``` Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value. This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by ```html <span>Employee</span><span class="..">(Department)</span> ``` in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it, ```xml <span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/> ``` since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change. Therefore, whenever a component's value changes (in our case, Shift1 becomes Shift2), it is never updated. In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution. To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render. opw-6128168 Forward-Port-Of: odoo/enterprise#115160 Forward-Port-Of: odoo/enterprise#115061
This update resolves an issue where holiday calculations were sometimes incorrect. The fix adjusts the domain used to retrieve holiday data, ensuring accurate holiday assignments for employees. This improves the reliability of our holiday management system.
Original PR description
Forward-Port-Of: odoo/odoo#261250
This update resolves a problem where users received duplicate notifications when submitting the email reminder form for events. The fix ensures notifications are displayed correctly and prevents unwanted redirects to talk pages, improving the user experience when adding events to their agenda.
Original PR description
This PR fixes the email reminder form with multiple commits: - Commit 1 fixes the notifications displayed when the email form is submitted as the messages of those notifications are redundant. - Commit 2 inserts the form inside the HTML body instead of the interaction's HTML since the surrounding HTML of this last one may cause display issues as with the <a> tag redirecting the users on the talks page when they click on the form which should not happen. Task-5347538 Forward-Port-Of: odoo/odoo#251468
This update corrects a bug that prevented the Point of Sale system from correctly identifying available printers. The fix ensures the system now properly considers both receipt and preparation printers, resolving a potential issue where no printers were displayed. This improves the overall reliability of the POS functionality.
Original PR description
We were looping over non existing `config.printer_ids`. It's either `config.receipt_printer_ids` or `config.preparation_printer_ids`. We now loop over a set containing values of both. Forward-Port-Of: odoo/odoo#259681
This update corrects a bug where archived email templates were incorrectly displayed in the applicant refusal wizard. The fix ensures that only active email templates are suggested, preventing confusion and ensuring accurate email communication during the application refusal process. This improves the user experience and data consistency.
Original PR description
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to…
Pre-requisites: --------------- 1. Create or duplicate any `hr.applicant` email template. 2. Archive the newly created template. 3. Archive the email template linked to a refuse reason. Steps to reproduce: ------------------------- 1. Install hr_recruitment. 4. Go to Recruitment > Applications > All Applications and open an applicant. 5. Click on the "Refuse" button to open the refuse wizard. 6. Click on the "Email Template" and click on 'Search More' 7. Observe available templates Issue: ------- If a refuse reason is linked to an archived email template, the wizard automatically pre-fills that archived template Cause: ---------- The `_compute_template_id` method automatically assigns the template from the refuse reason without checking whether the template is active, which allows archived templates to be pre-filled in the wizard. https://github.com/odoo/odoo/blob/aa2a7c0e5a5de970cdb8f6a7ba9f02ad75cf5078/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L91-L96 Solution: ----------- - Update `_compute_template_id` to ensure only active templates are automatically assigned. opw-5974244 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257580 Forward-Port-Of: odoo/odoo#251186
This update fixes an issue where the 'Hide lines at 0' feature was removing the report-level total line from printed reports like the Trial Balance. The change ensures that total lines, including the main report total, are always printed, regardless of the 'Hide lines at 0' setting. This improves the clarity and accuracy of financial reports.
Original PR description
When "Hide lines at 0" is enabled, printing e.g. the Trial Balance will drop the report-level "Total" line when printing. This commit fixes that. The issue was introduced in this commit[^1], which didn't consider total lines without a parent (i.e. root total lines). [^1]: https://github.com/odoo/enterprise/commit/7fec18b99eb2aa5ebc357dcad5f95f234db5b7d8 Forward-Port-Of: odoo/enterprise#114084
This update corrects a display issue in the employee attendance Gantt chart. Previously, flexible employees had their maximum working hours incorrectly hidden for longer schedules. Now, the chart accurately shows expected hours using a more flexible calculation, ensuring accurate tracking for all flexible employees.
Original PR description
For employees having a `resource_calendar_id` with `flexible_hours`, the max hours displayed in the gantt view were incorrectly `days * hours_per_day`. This fixes it by taking the most relevant data between `days * hours_per_day`, `weeks * hours_per_week`, both, or nothing if the range is more than a month. The new calculation is `(weeks * hours_per_week) + min((days * hours_per_day), (hours_per_week))` task 5075953 Forward-Port-Of: odoo/enterprise#105266
This update fixes a minor visual issue where the IM status icon in the user menu was slightly misaligned. The change centers the icon within its container, providing a cleaner and more professional user interface. This ensures consistent visual presentation and improves the overall user experience.
Original PR description
**Current behavior before PR:** Since this https://github.com/odoo/odoo/pull/246182, the IM status icon in the user menu appears misaligned with its surrounding context, causing a slight visual offset. **Desired behavior after PR is merged:** This commit ensures that the IM status icon is properly aligned by centering it within its container. task-[6012657](https://www.odoo.com/odoo/project/1519/tasks/6012657) | Before | After | |--------|--------| | <img width="308" height="46" alt="image" src="https://github.com/user-attachments/assets/214083b2-5013-41ab-a02f-8f8d510b1ac5" /> | <img width="311" height="43" alt="image" src="https://github.com/user-attachments/assets/9a77718c-84d4-4be8-8cc4-a65516e957cd" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request updates the core spreadsheet component used in Odoo. It addresses a bug where chart figures lingered after deletion and ensures the spreadsheet package is always the latest stable version. This improves the overall spreadsheet functionality and stability for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/45f9930d5a [REL] 19.2.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/45f9930d5a [REL] 19.2.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a0c7941d4e [FIX] chart: figure sometime still exist after chart deletion [Task: 6107235](https://www.odoo.com/odoo/2328/tasks/6107235) https://github.com/odoo/o-spreadsheet/commit/bc9fcef122 [FIX] package: saas-19.2 is no longer the latest stable [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) 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 addresses a rare crash that could occur when canceling drag sequences in the Odoo application. The fix ensures the 'cancel' callback is properly available before assigning it to a global variable, preventing the crash in situations where multiple sequences are initiated quickly. This improves overall application stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261014 Forward-Port-Of: odoo/odoo#260594
This update fixes an issue where group payments weren't accurately calculating installment amounts. Previously, the full bill amount was included, even for subsequent installments. Now, payments correctly reflect the full amount of the initial bill and only the next installment payment for multi-installment bills, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: 1- Install Accounting and make sure "Batch Payments" is enabled in settings 2- Go to [Accounting -> Vendors -> Bills] 3- Create two bills for the same vendor, ensuring one of them has multiple installments (i.e payment term with 3 installments) 4- Confirm the bills 5- In list view, select both bills and another bill from a different vendor and click on Pay 6- Select "Group Payments" and confirm the payment Description of issue: The batch payment of the first vendor has the full amount for both bills Expected behavior: The payment should consider the full amount of the first bill and the first installment only of the second bill opw-5969972 Forward-Port-Of: odoo/odoo#260933 Forward-Port-Of: odoo/odoo#257871
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic line links during editing, preventing orphaned analytic lines and improving the bank reconciliation process.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update fixes an error in how holiday leave time off is calculated. Previously, public holidays were incorrectly included in the time off duration, leading to inaccurate hours reported. The fix ensures that approved time off aligns with the expected 8-hour workday, even when public holidays are present.
Original PR description
# Setup You'll need a User with : - An active contract (for easiness of testing, a contract that started long ago with 8hrs/day) # How to reproduce - Create a new Time Off type with "Ignore Public…
# Setup
You'll need a User with :
- An active contract (for easiness of testing, a contract that started long ago with 8hrs/day)
# How to reproduce
- Create a new Time Off type with "Ignore Public Holidays" enabled
- Create a Public Holiday for Period X
- Create A Time Off request for the User for a Period Y that contains Period X
- Go to the Time Off Ledger
- Remove the Missing Hours filter and search for the dates in Period Y
Exemple of periods :
- Period X => Feb 10 2026 - Feb 10 2026
- Period Y => Feb 9 2026 - Feb 11 2026
# The problem
The "Approved Time Off" and "Difference" values are wrong.
With the given exemples, we'll see Feb 9 and Feb 11 with "Approved Time Off" values of 12hrs, which is wrong since the employee is supposed to work 8hrs a day, so he should have a time off of also 8hrs.
# Cause
The calculation for "Approved Time Off" is the following :
Divide the `number_of_hours` of a hr_leave
By the number of working days during the period of the leave
Using our exemple, we get :
`number_of_hours` = 24hrs
number of working days = 2
Approved Time Off = 24hrs / 2 => 12hrs, but we expect 8hrs
The `number_of_hours` is correct since we checked "Ignore Public Holidays" (which actually means : include the public holidays in the number of hours of a leave)
The problem is that the aggregation for the number of working days excludes automatically
public holidays, without paying attention to the value of "Ignore Public Holidays" :
https://github.com/odoo/odoo/blob/5e623af55fba64e812db6bcaf06d8f7c5d08f055/addons/hr_holidays_attendance/report/hr_leave_attendance_report.py#L193-L202
Explanation for this part of the query : we only keep days where there is no record in
resource_calendar_leaves (`WHERE rcl2.id IS NULL`) that contains that day
and that are considered public (`AND rcl2.resource_id IS NULL`)
# Proposed Solution
We add a `JOIN hr_leave_type` to be able to get the value for
`include_public_holidays_in_duration` ("Ignore Public Holidays").
Then, we make it so we exclude the Public Holidays only if that value is
false (`AND NOT lvt.include_public_holidays_in_duration`)
opw-6082422
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258963This update corrects a warning message that incorrectly flagged transactions using the Cash Basis accounting method as having an inactive Construction Industry Scheme. The fix ensures that CABA entries, which should be excluded from this check, are not triggering unnecessary warnings. This improves the accuracy of reporting for businesses using Cash Basis.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
This update ensures that survey invitations are sent in the recipient's preferred language, regardless of whether they speak multiple languages. Previously, invitations were often incorrectly sent in English to users with other language preferences. This fix improves the user experience and avoids confusion for international users.
Original PR description
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install…
When sending survey invitations to a group of recipients with different language preferences, some recipients would receive the invitation in the incorrect language. ### Steps to reproduce 1. Install the "Surveys" module and activate a second language (e.g., Dutch). 2. Create a survey and ensure its invitation template has translations for both languages. 3. Create two contacts: one with English as their language and another with Dutch. 4. On the survey, click "Share" and add both contacts as recipients. 5. Send the invitations. 6. The contact with Dutch preferred language receives the email in English. ### Cause By default, the wizard uses a single language for every email in a batch. While it can switch this language if everyone in the group speaks the same tongue, it fails to do so for mixed-language groups. Adding compute_lang=True fixes this by telling the system to look up and use the correct language for each recipient one by one. opw-5868581 Forward-Port-Of: odoo/odoo#259967 Forward-Port-Of: odoo/odoo#246778
This update fixes an issue where stock wasn't being properly reserved for delivery orders when stock arrived at a child location within the warehouse system. Previously, the system didn't recognize the connection between the parent and child locations, leading to incorrect stock availability. This ensures accurate stock reservations and prevents over-delivery issues.
Original PR description
Steps to reproduce: - Create a storable product with no stock on hand - Create a delivery order from WH/Stock → state is "Waiting for Availability" - Create a receipt with destination WH/Stock/Shelf1 and validate it Problem: The incoming quantity is not reserved against the waiting delivery, even though WH/Stock/Shelf1 is a child of WH/Stock. opw-6124879 Forward-Port-Of: odoo/odoo#261072
A bug preventing the custom color settings for self-ordering kiosks in Odoo was fixed. The issue stemmed from a missing configuration value being passed during data loading, which defaulted to the standard color. This update ensures self-ordering kiosks now correctly display the user-defined color scheme.
Original PR description
The background color configured for the self ordering / kiosk was not applied. This was caused because the `self_ordering_primary_color` field was not sent to the self order when loading the data, resulting in the default color always being used. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6149865
28 changes
New functionality added to Odoo
This update introduces a new module, 'obox,' designed to connect and manage hardware devices similar to the Odoo FDM. The initial phase focuses on allowing users to register and view basic information (IP address and services) for their Obox devices, paving the way for future device integration.
Original PR description
The Obox (same platform as the Odoo FDM for Belgium) will allow interfacing with hardware devices, and is intended to replace the functionality of the IoT box. This commit only adds the ability to pair an Obox to the database, and see its IP and available services. see odoo/obox#118
Enhancements to existing features
This update enhances the reporting functionality within the Enterprise version of Odoo by making return type menu options consistently available. Previously, these options were restricted to debug mode. Now, they're accessible to authorized users, streamlining the reporting process.
Original PR description
Before, the menu return types in configuration was only available in debug mode. Now it is available for the group `account.group_account_readonly` task-5912751 Forward-Port-Of: odoo/enterprise#114830
Resolved issues and error corrections
This update resolves a technical error that was preventing the point-of-sale system from functioning correctly. The issue stemmed from a previous code change that hadn't been fully integrated into the saas-19.1 environment. This fix ensures the currency testing within the pricelist feature is working as expected.
Original PR description
Fixes runbot error https://runbot.odoo.com/odoo/runbot.build.error/243302 Needed because commit 9674a712d951 (https://github.com/odoo/odoo/pull/252521) is not yet forward-ported to saas-19.1.
This update fixes an issue where group payments were incorrectly applying the full amount of multiple bills to a single payment. Now, group payments accurately reflect the first installment of bills with multiple payment terms, ensuring correct accounting and payment processing. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: 1- Install Accounting and make sure "Batch Payments" is enabled in settings 2- Go to [Accounting -> Vendors -> Bills] 3- Create two bills for the same vendor, ensuring one of them has multiple installments (i.e payment term with 3 installments) 4- Confirm the bills 5- In list view, select both bills and another bill from a different vendor and click on Pay 6- Select "Group Payments" and confirm the payment Description of issue: The batch payment of the first vendor has the full amount for both bills Expected behavior: The payment should consider the full amount of the first bill and the first installment only of the second bill opw-5969972 Forward-Port-Of: odoo/odoo#260933 Forward-Port-Of: odoo/odoo#257871
This update fixes an issue where product URLs in multilingual websites incorrectly included the category. Now, the canonical URL for products in non-default languages accurately reflects the product itself, without the category prefix. This ensures consistent and correct links for customers browsing in different languages.
Original PR description
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to…
Issue: --- Canonical address is not correctly calculated in non-default lang. Steps to reproduce: 1- Create a website with 2 lang: en, fr 2- Create a product with a website category. 3- Navigate to the shop in fr. 4- Open the category, then open the product. 5- Open console, and search for canonical. As you see, in the second language, the canonical address includes the category address which is wrong. If you visit in the default lang, the canonical correctly refers to the url without category. Cause: --- This is because `_get_canonical_url` override relies on `self.env['ir.http']._match`, which will not work with an url prefixed by language code, raising `NotFound`. This leads to rule to be set as `None`. As a result canonical address will be set as the canonical address from `website` module's implementation, which doesn't take website category case into account. This lead to canonical address of `/lang-code/shop/category/product` to be itself. opw-6086206 Forward-Port-Of: odoo/odoo#258834
This update ensures that stock is properly reserved against waiting delivery orders, even when the destination warehouse is a child location. Previously, incoming stock wasn't automatically linked to these waiting orders, leading to potential stock discrepancies. This fix improves inventory accuracy and order fulfillment reliability.
Original PR description
Steps to reproduce: - Create a storable product with no stock on hand - Create a delivery order from WH/Stock → state is "Waiting for Availability" - Create a receipt with destination WH/Stock/Shelf1 and validate it Problem: The incoming quantity is not reserved against the waiting delivery, even though WH/Stock/Shelf1 is a child of WH/Stock. opw-6124879 Forward-Port-Of: odoo/odoo#261072
This update fixes a potential issue where users could falsely validate signatures in draw mode using Firefox and similar browsers. Now, the system requires a visible signature drawing before validation can occur, ensuring signatures are only confirmed when genuinely signed.
Original PR description
On Firefox and similar browsers, it was possible in some cases to validate a signature field in draw mode without actually drawing a signature, allowing the document signature to be confirmed with an empty signature. This change ensures that a signature field in draw mode can only be validated when the signer has effectively drawn a visible signature. task-6117312 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#259100
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, making it easier to understand and interpret.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where copying and pasting content from the blog post editor unexpectedly modified the original field data. The fix adds a setting to the editor to prevent copying outside of the editable area, ensuring data integrity and preventing unintended changes to the source records.
Original PR description
Problem: When copying the blog post title and pasting it elsewhere, editing the pasted content unexpectedly modifies the original field source. Cause: The copied HTML retains `data-oe-*` attributes, causing the editor to treat the pasted content as a field binding and propagate changes back to the original record. Solution: `contenteditable="true"` should be added on fields (`o_savable`) to prevent copying outside of savable area. Steps to Reproduce: - Copy title of blog post. - Paste it elsewhere in editable. - Edit the pasted text. - Observe the original field source also changes. opw-6105714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes the timesheet assistant view more user-friendly by implementing small adjustments for better clarity. These changes focus on enhancing the overall experience and usability of the timesheet management process. The improvements are intended to streamline workflows and reduce potential confusion.
Original PR description
Improve the assistant view with small adjustments to enhance clarity and user‑friendliness.
This update resolves an issue where CFDI generation for payroll payslips failed with errors due to discrepancies in decimal precision. The fix ensures all payroll amounts are rounded to 2 decimal places before XML formatting, aligning with CFDI requirements and preventing errors. This ensures accurate CFDI generation and compliance.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update fixes a rare crash that could occur when canceling drag sequences in the Odoo application. The issue stemmed from a timing problem with how the system registered and executed cancellation callbacks. This change ensures the callback is available before assignment, preventing the crash and improving overall stability.
Original PR description
### [FIX] web: fix crash when cancelling drag sequence Before this commit: drag sequences could be aborted by new drag sequences; the way this worked is that a new sequence would register its "cancel" callback in a global variable, and when another sequence is started, it calls that variable to cancel the previous one. The issue was that the variable was assigned too early; before the actual "cancel" callback was available. This means that in edge cases where 2 sequences would be triggered in less than (effectively) a resolved promise, the callback would not be available and a crash would occur. This commit moves the variable assignment *after* the "cancel" callback is made available, ensuring there is no crash. Runbot [243113](https://runbot.odoo.com/odoo/error/243113) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261014 Forward-Port-Of: odoo/odoo#260594
This update corrects a bug where users received duplicate email notifications when submitting the email reminder form for events. The fix ensures that only one notification is displayed, and the form is now correctly embedded within the event page's HTML to prevent unwanted redirects. This improves the user experience and avoids redundant communication.
Original PR description
This PR fixes the email reminder form with multiple commits: - Commit 1 fixes the notifications displayed when the email form is submitted as the messages of those notifications are redundant. - Commit 2 inserts the form inside the HTML body instead of the interaction's HTML since the surrounding HTML of this last one may cause display issues as with the <a> tag redirecting the users on the talks page when they click on the form which should not happen. Task-5347538 Forward-Port-Of: odoo/odoo#251468
A recent update resolved a problem where newly added overtime lines on attendance records would disappear after a page refresh. To fix this, the system now prevents users from adding new overtime lines, ensuring data consistency and accurate work entry synchronization. This improves the reliability of overtime tracking.
Original PR description
Steps to reproduce: - On an attendance with overtime, click the "Add a line" button and add a new overtime line - Refresh the page - The newly added line has disappeared and navigating to work entries causes a traceback How it was fixed: Disabled the ability to add a new overtime line. Task ID: 5899657 Forward-Port-Of: odoo/odoo#248431
This update corrects a bug that was incorrectly generating overtime entries on previous days due to an issue with how work entries were being regenerated. The fix ensures accurate overtime calculations by considering employee timezones when searching for work entries, preventing incorrect date calculations.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#107266
This update resolves an issue in the HR Holiday module that was preventing accurate holiday calculations. The fix corrects a domain used to filter holiday leaves, ensuring that the system correctly identifies and applies available leave periods. This improves the reliability of holiday scheduling and reporting.
Original PR description
Forward-Port-Of: odoo/odoo#261250
This update fixes a bug that prevented links within 'Button' snippets on the website from being translated. Previously, these links were excluded from the translation process. Now, all button links are correctly tagged for translation, ensuring consistent localization across the website.
Original PR description
Before this commit, links on `Button` inner snippets dropped from the sidebar (not through powerbox) were never translatable. `o_translate_inline` was only added in link insert flows or when already present in snippet template, not when dropping inner button snippets. As a result, dropped button anchors were missing `o_translate_inline` and were filtered out from translatable inline links. Steps to reproduce: - Enter edit mode. - Drag and drop a `Button` inner snippet. - Save. - Switch to translation mode. - Try to edit the button link: it cannot be edited. This commit adds handling on snippet drop to tag dropped anchors with `o_translate_inline`. task-5943645 Forward-Port-Of: odoo/odoo#260423 Forward-Port-Of: odoo/odoo#249019
This update resolves a technical issue causing a '405 Method Not Allowed' error during logout. The change allows both GET and POST requests to the logout route, ensuring a smoother user experience and preventing errors when accessing the logout feature directly from a browser link.
Original PR description
Steps to reproduce: 1. Open a website 2. Go to the signup page and create an account 3. Click on the logout button Issue: A "405 Method Not Allowed" error occurs when logging out. The logout route only accepts POST requests, but in here a GET request is triggered (e.g., redirect flow), causing the error. Before this commit: Accessing `/web/session/logout` could result in a redirect to `/odoo` with a GET request, which is not valid since the route expects POST. After this commit: Allow both GET and POST methods on the logout route: POST requests handle the actual logout operation as expected GET requests are accepted to avoid 405 errors when we write direct on the browser. task-6023075
This pull request updates the core spreadsheet component (o_spreadsheet) to the latest version, ensuring users have the most recent functionality and bug fixes. Specifically, it addresses issues related to data formatting and color synchronization within the spreadsheet, improving overall performance and reliability. This update is a routine maintenance task.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4e3d2038e4 [REL] 19.1.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4e3d2038e4 [REL] 19.1.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d21a87b75b [FIX] side_panel: preserve spaces in DV values and fix color mapping [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) https://github.com/odoo/o-spreadsheet/commit/201f1ba213 [FIX] side_panel: stabilize list criterion color sync [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) 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 resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause data inconsistencies and orphaned analytic lines. The fix ensures accurate account updates by disabling inverse methods during editing and explicitly recreating analytic lines upon saving, preventing data errors.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update corrects a visual issue where adding a new shift sometimes resulted in duplicate employee names appearing in Gantt views. The fix ensures that employee display updates correctly, preventing the display of the same employee multiple times. This improves the clarity and accuracy of shift scheduling.
Original PR description
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An…
Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee. It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have: ``` +--------------+ | Shift1 User1 | +--------------+ ``` Add another shift (Shift 2) with User2. We'll have: ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User1 | +--------------+ ``` instead of ``` +--------------+ | Shift1 User1 | +--------------+ | Shift2 User2 | +--------------+ ``` Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value. This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by ```html <span>Employee</span><span class="..">(Department)</span> ``` in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it, ```xml <span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/> ``` since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change. Therefore, whenever a component's value changes (in our case, Shift1 becomes Shift2), it is never updated. In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution. To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render. opw-6128168 Forward-Port-Of: odoo/enterprise#115160 Forward-Port-Of: odoo/enterprise#115061
This pull request corrects a visual issue where an empty state was sometimes displayed on the Odoo website. Previously, users might have seen an unexpected blank screen when certain sections were empty. This change ensures a consistent and professional user experience by properly handling empty states, improving overall website usability. This is a minor fix focused on visual presentation.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that the Slovak VAT tax reports generated by Odoo comply with the official Slovak XML format. Specifically, the formatting of editable fields has been adjusted to use the required 2 decimal place precision, as mandated by the Slovak VAT XSD schema. This ensures accurate data exchange with tax authorities.
Original PR description
As per the Slovak VAT XSD schema, editable fields must use a precision of 2 decimal places. So updating here to ensure compliance with the official XML format. Reference: https://ekr.financnasprava.sk/Formulare/XSD/dph2025.xsd
This update resolves a failing test related to WorldLine integration within the self-order system. The fix ensures that both necessary modules (`pos_self_order_iot` and `pos_iot_worldline`) are present before running the test, preventing errors when the `pos_iot_worldline` module is not installed.
Original PR description
To test WorldLine in self order, we need both `pos_self_order_iot` and `pos_iot_worldline`. We then skip the test if `pos_iot_worldline` isn't installed.
This update resolves an issue where holiday allocations were being unnecessarily approved multiple times, potentially causing delays. The fix removes a redundant approval step and streamlines the process, ensuring holiday requests are processed efficiently. This improves the overall reliability of the holiday request system.
Original PR description
Cause: In this commit https://github.com/odoo/odoo/pull/258520/changes/1b6f3a1335302ca029ab62a25c7bcff0953b99be we accidently added a line to approve allocation which might already be approved. Fix: Remove this line and move the accrual filter right before the first action approve opw-5888023 Forward-Port-Of: odoo/odoo#260158
This update corrects a warning message appearing when using the Cash Basis accounting method with CIS-related transactions. The fix ensures that the CIS inactive check is applied correctly only to purchase-related documents, preventing unnecessary alerts for valid transactions. This improves the user experience and reduces potential reporting issues.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
This update corrects a bug that caused overtime lines to be duplicated during the regeneration process, leading to system crashes. The change ensures the correct timezone is used when identifying overtime periods, preventing the creation of duplicate entries and improving stability.
Original PR description
Issue: ---------------------------------------- With a specific configuration it can happen that overtime lines are not deleted when regenerating them, causing crashes in…
Issue: ---------------------------------------- With a specific configuration it can happen that overtime lines are not deleted when regenerating them, causing crashes in `_set_real_overtime_intervals()` for example, because several records will be linked in the same interval. Steps to reproduce: ---------------------------------------- - Have a calendar where: - Attendance on Sunday - No attendance on Monday - Timezone = 'America/New_York' - Select this calendar for an employee in UTC timezone with the default overtime ruleset - Create an attendance for this employee: - Start: 10AM on a Sunday - End: 1AM the next day, Monday - It should have 2 overtimes, one on Sunday the other on Monday - Go on the ruleset and click "Regenerate ovetimes" - Go back to the attendance and notice the overtime line for Monday is duplicated - If you go in Payroll > Work Entries > Work Entries and select the time frame to see the attendance, it will crash Cause: ---------------------------------------- We use `_get_tz()` to get the timezone in which we want to convert the attendance start and end to, then create the domain to search for the overtimes. But `_get_tz()` returns the calendar timezone, not the resource one, which is the one used in the attendance and overtime lines dates. When converting the start and end of the attendance to calendar tz, they both end up on Sunday. So the domain includes the whole week before the attendance but not the Monday where there is an overtime line. So only the Sunday overtime line is selected, and only this one is [unlinked](https://github.com/odoo/odoo/blob/ca8f3e6f054748e8951a2cd05ccdc2d36388e928/addons/hr_attendance/models/hr_attendance.py#L304) leaving the one on Monday, which is later recreated. Solution: ---------------------------------------- Use `employee.tz` instead of `_get_tz()`. opw-6067969 Forward-Port-Of: odoo/odoo#259809
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, appearing only in English. The change ensures that contact types are correctly translated to the user's preferred language, matching the translation displayed in the Kanban view. This improves the user experience for international users.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/odoo#260815 Forward-Port-Of: odoo/odoo#257539
6 changes
Resolved issues and error corrections
This update allows administrators to override the automatic resetting of subscription user accounts. Previously, this process was difficult to control, but now it's easily configurable, providing greater flexibility in managing user access within the subscription model. This change ensures better control over user lifecycle management.
Original PR description
After this commit, the auto resetting of subscription user is overridable. Doing business logic in CRUD methods makes them impossible to bypass, by encapsulating the logic in another method, it would be easily overridable. Forward-Port-Of: odoo/enterprise#114459 Forward-Port-Of: odoo/enterprise#114055
This update fixes a minor display issue in the Helpdesk dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, providing a clearer and more intuitive representation of performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic line links during editing, preventing orphaned analytic lines and improving the bank reconciliation process.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update fixes an issue where the contact type for related contacts wasn't being translated in the contact list view, appearing only in English. The change ensures that contact types are correctly displayed in the user's preferred language across all views, improving the user experience. This resolves a discrepancy between the list view and the Kanban view.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#114786
This update corrects a warning message appearing when using the UK Construction Industry Scheme (CIS). The fix prevents the system from incorrectly flagging vendor bills with CIS tax as inactive, ensuring accurate reporting and reducing unnecessary alerts. This change improves the user experience for businesses utilizing the UK tax reporting module.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
This update resolves an issue where the product count in the stat button on Sale Order Lines created from tasks would incorrectly display '0 products' until the task was saved. Now, the counter accurately reflects the products in the order line, regardless of whether the task is saved immediately.
Original PR description
Previously, when creating a Sale Order Line on the fly from a task, the product count in the stat button showed '0 products' until the task was saved. Now, the counter no longer drops to 0 when the record is not saved. task-4276677 Forward-Port-Of: odoo/enterprise#113334 Forward-Port-Of: odoo/enterprise#95100
4 changes
Resolved issues and error corrections
This update fixes a potential issue where users could incorrectly validate signatures in draw mode using Firefox and similar browsers. Now, the system requires a visible signature drawing before validation, ensuring signatures are only confirmed when a genuine signature is present. This improves the accuracy and reliability of our document signing process.
Original PR description
On Firefox and similar browsers, it was possible in some cases to validate a signature field in draw mode without actually drawing a signature, allowing the document signature to be confirmed with an empty signature. This change ensures that a signature field in draw mode can only be validated when the signer has effectively drawn a visible signature. task-6117312 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#259100
This update fixes a minor display issue in the Helpdesk dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, it's displayed as a score out of 5, providing a clearer and more intuitive representation of performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update addresses a potential error in the account reporting module that could occur when clients use custom modules with similar field names. The fix ensures the system correctly identifies column references, preventing errors and ensuring accurate reporting. This improves stability and reliability for all users.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665
This update resolves an issue where the automated invoice retrieval process (cron job) in Odoo Enterprise wasn't correctly identifying the target company when multiple companies were involved. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of reporting. This improves data accuracy for multi-company users.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#114937 Forward-Port-Of: odoo/enterprise#113254
1 change
Resolved issues and error corrections
This update resolves an issue where CODA import files with incremented detail sequences (3.2) were causing errors. Banks sometimes provide files with updated transaction details, and this fix allows Odoo to correctly process these files without triggering a parsing error. This ensures seamless bank statement imports for our BE customers.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
14 changes
Enhancements to existing features
This update enhances the user experience by adding custom loading messages during website generation. These messages provide more helpful feedback to users while the website is being built, leading to a smoother and more informative process. This change improves the overall perception of website performance.
Original PR description
\* = website_generator Following the improvements in `website_loader`, which now support passing custom loading messages, this commit introduces custom messages for the website generator. These messages provide more contextual feedback during the loading process, enhancing the user experience. <br/> Community PR: odoo/odoo#193974 task-[4252688](https://www.odoo.com/odoo/project/974/tasks/4252688)
This update enhances the Odoo Website Builder AI agent by granting access to image generation and web search tools from the start of conversations. Previously, the agent wasn't automatically aware of these features, limiting its functionality. Now, the agent can leverage these tools for a more comprehensive and dynamic user experience.
Original PR description
__Before commit__ Since odoo/enterprise@be7cb24c, the AI topics are not loaded in the context from the start. Therefore, although the Website Builder AI topic has access to the image generation tool, the agent isn't necessarily aware of it at the start. Moreover, the Website Builder agent is currently unable to perform web searches. __After commit__ The Website Builder agent now has access to the image generation topic as well as the web search topic. It will therefore be aware of those tools from the start of the conversation. task-6143594 Forward-Port-Of: odoo/enterprise#114871
This update enhances the stability of the Odoo Spreadsheet Edition by introducing a singleton UUID generator. This ensures consistent and reliable unique identifiers are used across various spreadsheet components, reducing potential conflicts and improving overall performance. The change improves the robustness of the spreadsheet functionality.
This update enhances the holiday pay calculations in the Odoo Enterprise system by adding specific tax provision rules for employee and worker types. This ensures accurate tax reporting related to holiday pay, aligning with Belgian tax regulations. The changes include new data and updated tests to reflect these new rules.
Original PR description
Add Tax provision informative rules for holiday pay . Add holiday_pay_provision_employee . Add holiday_pay_provision_worker . Add & Modify corresponding tests task-6032859
Resolved issues and error corrections
This update fixes an issue where resource leaves weren't properly reflected in Google Calendar availability, leading to incorrect booking options. The team also removed unnecessary code related to minimum schedule hours, as Google Reserve slots are pre-defined. This ensures accurate availability and a smoother booking experience.
Original PR description
Resources on leave were still showing as available in BatchAvailabilityLookup responses because unavailabilities were not checked. Also remove the min_schedule_hours offset copied from the frontend logic. It is not relevant for Google Reserve as slots are pre-built in the feeds. Task-6150788 Forward-Port-Of: odoo/enterprise#114793
This update fixes an issue where signature overlays were causing data loss in PDF documents. Now, the original PDF structure, including metadata and bookmarks, is fully preserved when signatures are added. This ensures consistent and accurate PDF documents.
Original PR description
Instead of rebuilding the PDF by copying content, metadata, and bookmarks, we now duplicate the original document first and then apply the signature overlays. This ensures the full structure and settings are preserved without loss. task-6083291 Forward-Port-Of: odoo/enterprise#115048 Forward-Port-Of: odoo/enterprise#114618
This update resolves an issue where CFDI generation for payroll payslips failed due to discrepancies in decimal precision. The fix ensures all payroll amounts are rounded to 2 decimal places before CFDI generation, aligning with Mexican tax regulations. This prevents errors and ensures accurate CFDI stamping.
Original PR description
Currently, if the company is configured with a 4-decimal currency, the CFDI generation for payslips might fail with NOM111 and CFDI40119 errors. This occurs because the calculation of totals and subtotals uses the raw unrounded floats, which can cause penny differences when the XML template formats the individual lines to 2 decimal places. This commit forces all payroll concept amounts to be explicitly rounded to 2 decimal places before accumulating the totals. This ensures that the sum of the formatted XML nodes precisely matches the total and subtotal values reported in the CFDI. Accounting might require a higher decimal precision for the company's currency (e.g., 4 decimals for inventory). However, payroll CFDI stamping strictly requires 2 decimal precision. This fix isolates the payroll CFDI calculations from the company's currency settings. Forward-Port-Of: odoo/enterprise#114936
This update prevents unnecessary warnings from appearing when a task template is moved to a project that doesn't support timesheets. This change ensures a smoother workflow for users managing task templates and avoids distracting notifications. It addresses a previous issue identified in a related community pull request.
Original PR description
A task template should not trigger any warning about timesheets that remain in the previous project when changing its project to a non-timesheetable project. related Community PR: https://github.com/odoo/odoo/pull/230118 task-5140018
This update corrects a technical issue where a duplicate record was incorrectly introduced in the French reporting module (l10n_fr_reports). The fix removes this redundant record, ensuring accurate reporting data and preventing potential data inconsistencies. This resolves a minor technical problem.
Original PR description
this forward port wrongly introduced an already existing record https://github.com/odoo/enterprise/pull/114739 Forward-Port-Of: odoo/enterprise#114907
This update resolves an issue where changing the account on bank reconciliation lines with analytic distributions would cause errors and data inconsistencies. The fix ensures accurate account updates by properly managing analytic lines during editing, preventing orphaned lines and maintaining data integrity.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update resolves a technical error in the processing of French tax returns (liasse fiscale). A missing call to the parent function caused a test failure, which has now been corrected. This ensures accurate reporting and compliance for French businesses using Odoo Enterprise.
Original PR description
When merging the sending of the liasse fiscale, super() wasn't called anymore in action_submit and led to an assertError in test_state_progression() test
```
FAIL: Subtest TestAccountReturn.test_state_progression (return_type=account.return.type(186,))
Traceback (most recent call last):
File "/data/build/enterprise/account_reports/tests/test_account_returns.py", line 2087, in test_state_progression
self.assertEqual(account_return.state, 'paid')
AssertionError: False != 'paid'
```
runbot-275061
Forward-Port-Of: odoo/enterprise#114585A recent change to the l10n_mx_edi module broke a key test related to rounding calculations for Mexican tax invoices. This update reverted the rounding mode to 'mixed', resolving the test failure. This ensures accurate tax calculations are being verified within the module.
Original PR description
https://github.com/odoo/odoo/pull/255574 change the rounding mode back to mixed. This break the test modified in this PR. opw-5963855 Forward-Port-Of: odoo/enterprise#114081
This update corrects a warning message that incorrectly flagged transactions using the Cash Basis accounting method as having an inactive Construction Industry Scheme. The fix ensures that CABA entries are properly excluded from this check, preventing unnecessary alerts and improving the accuracy of reporting. This change impacts users utilizing Cash Basis accounting and CIS reporting.
Original PR description
Currently, journal entries may be flagged for the CIS inactive partner check, causing unnecessary warning. Steps to reproduce: - Install l10n_uk_reports_cis. - Accounting > Configuration > Settings, enable "Cash Basis" - Open "20% CIS" Purchase tax - Set "Tax Exigibility" to "Based on Payment" and add a Cash Basis Transition Account - Set Outstanding account on the Bank journal - Create a partner and enable (Accounting tab) Construction Industry Scheme" - Create a vendor bill for this partner with a the 20% CIS tax - Register payment to the Bank journal - Open the created CABA entry Issue: Warning will be shown "Construction Industry Scheme hasn't been enabled for this vendor." Analysis: The warning flag is incorrectly triggered because the CABA entry has `invoice_line_ids` field set. However entries should be excluded by this check as it should only apply to purchase-related documents. opw-5942603 Forward-Port-Of: odoo/enterprise#113003
A minor bug preventing the generation of EC sales returns has been fixed. This issue arose after a recent update to the ec sales list report, and was caused by a simple typo. This ensures that sales returns are accurately tracked and reported.
Original PR description
With the rework of the ec sales list report(https://github.com/odoo/enterprise/commit/4096c1fcbd7f31f70153058d2e3f9eab6d82e356#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29), the return generation of this type became generic but a small bug appeared. It was not generating anymore because of a typo. Forward-Port-Of: odoo/enterprise#114815
5 changes
Resolved issues and error corrections
This update resolves an issue where CODA bank statement imports would fail due to discrepancies in the detail sequence (3.2). Banks are now sending files with incremented sequences, which the Odoo system now correctly handles without triggering an error. This ensures seamless import of bank statements from key Belgian financial institutions.
Original PR description
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2…
### Issue: Some banks provide CODA files that do not strictly follow the specification, and increment the detail sequence on 3.2 https://febelfin.be/media/pages/publicaties/2023/febelfin-standaarden-voor-online-bankieren/5607daeda5-1754302976/standard-coda-2.7-en.pdf Importing such files raises an error: `Error R3004: CODA parsing error on information data record 3.2, seq 00020002! Please report this issue via your Odoo support channel.` ### Cause: The parser compared the full `infoLine['ref']`, while only `infoLine['ref_move']` needs to remain consistent https://github.com/odoo/enterprise/blob/a6efef92b86d95e05245c4ccf26324d37cc153e6/l10n_be_coda/models/account_journal.py#L683-L698 The `infoLine['ref_move_detail']` (3.2 sequence) change should not block import when incremented and should not trigger an error ### Steps to reproduce: - Install `l10n_be_coda` and switch to the `BE company` - Import a CODA file with incremented 3.2 detail sequence (e.g., files available in related tickets or test data) Before the fix, the error is trigger opw-6071761 Forward-Port-Of: odoo/enterprise#113904
This update fixes a minor display issue in the Helpdesk app's performance dashboard. Previously, the 7-day average rating was shown as a percentage, which was confusing for users. Now, the rating is displayed as a score out of 5, providing a clearer and more intuitive representation of performance.
Original PR description
Steps to reproduce: - Open the Helpdesk app with demo data. - Check the "My Performance" section of the dashboard. Current behavior: - "Avg Last 7 days" is shown as "3.50 %". Expected behavior: - "Avg Last 7 days" is shown as "3.5 / 5". Issue: The backend already computes `7days.rating` as a 0-to-5 average, but the frontend dashboard template appends a "%" suffix. Solution: Update the Helpdesk dashboard template to display the 7-day average as a score out of 5 instead of as a percentage. task-5998903 Forward-Port-Of: odoo/enterprise#109804
This update resolves an issue where changing the account on a bank reconciliation line caused unexpected behavior and data inconsistencies. The fix ensures that account changes are applied correctly, preventing orphaned analytic lines and maintaining accurate financial records. This improves the reliability of bank reconciliation processes.
Original PR description
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic…
Before this commit, editing a line with an analytic distribution caused inconsistent behavior when changing the account. When an analytic distribution was present, editing the line created analytic lines linked to the move line. However, changing the account from the form view in the bank reconciliation widget triggered _inverse_account_id, which in turn called _inverse_analytic_distribution. This resulted in unlinking the analytic_line_ids from the move line, preventing the account change from being applied. On a second attempt, the account could be modified because there were no longer any analytic lines to unlink. This led to orphaned analytic lines not linked to any journal item. To fix this, the inverse method is now disabled while editing the line in the form view. Upon saving, the analytic_line_ids are explicitly unlinked, and _create_analytic_lines is triggered during the update to correctly recreate the analytic lines. opw-6107329 Forward-Port-Of: odoo/enterprise#114863
This update fixes an issue where the contact type for related contacts wasn't being translated to the user's language in the contact list view. It ensures that contact information, including contact type, is displayed correctly regardless of the user's language setting. This improves the user experience and consistency across the system.
Original PR description
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user…
Problem: When the contact type is set for a related (child) contact, the contact type is shown in English next to the contact name in the contact list view. It should be translated to the user language. It is correctly translated in the Kanban view. Steps to reproduce: 1. Install the Contacts app. 2. Create a contact or go to an existing contact 3. Add a related (child) contact and set its contact type to any type (i.e. Invoice Address) 4. Change the user language to any language other than English 5. Go back to the contact list view and check the name of the related (child) contact. See how the contact type appearing in the name is in English instead of being translated, while it is correctly translated in the Kanban view. Cause: The list view uses the 'complete_name' field which is not translated, while the Kanban view uses the 'display_name' field which is translated. Solution: Use the 'display_name' field instead of 'complete_name' in the list view. opw-5947987 Forward-Port-Of: odoo/enterprise#114786
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The change ensures accurate tax return calculations by isolating company-specific rounding data.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#114942 Forward-Port-Of: odoo/enterprise#110652
8 changes
New functionality added to Odoo
This update introduces automated deposit management for rental products within Odoo Enterprise. It allows businesses to automatically calculate and track deposits on rental orders, and now extends this functionality to Website Sale rentals. The system prevents manual quantity changes to rental products when a deposit is present, ensuring accurate deposit tracking.
Original PR description
After this commit: - Added default deposit product setting. - Enabled deposit requirement and amount on the product form. - Automatically calculates and adds deposit to order line. - Deposit line is created dynamically for single or multiple rental products. - Deposit line updates automatically when the rental product is modified. - If the main product exists => Users cannot manually update the quantity or remove the deposit line. - if the rental product quantity is set to 0 => The corresponding deposit line is removed automatically. - Extended deposit feature to Website Sale.
Enhancements to existing features
This update introduces a new option within the Point of Sale (POS) settings that allows users to automatically calculate quantity based on product price, particularly for products with weight or volume measurements. Enabling this feature changes the behavior of the price button to set quantity instead, streamlining order entry for relevant products.
Original PR description
After this commit : - `Quantity Set By Prices` option in POS settings. - Applicable UoM Categories: Works for products with **_Weight or Volume_** units of measurement. - Toggle Option in POS Interface: An action button is used to enable/disable the feature during a session. - Modified Price Button Behavior: When enabled, the Price button sets quantity instead of price.
Resolved issues and error corrections
This update fixes an issue where date-based sorting in financial reports was inconsistent, particularly when using the 'From the very start' period. The change ensures that string-type external values are now correctly ordered by date, improving the accuracy and reliability of report data.
Original PR description
Ensure string-type external values are correctly sorted by date when using the "most_recent" formula. This resolves an issue where values appeared unordered, especially for expressions using the "From the very start" period. task-5951888 Forward-Port-Of: odoo/enterprise#113837
This update fixes a bug that prevented users from correctly scraping component information from manufacturing orders created by others. The issue stemmed from incorrect access rights, specifically related to analytic account lines. This ensures accurate reporting and data retrieval for timesheet-related tasks.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989
This update resolves an issue where stock reservations weren't always fully completed when using the 'Smallest number of packages' removal strategy. The fix ensures that all available quantities are correctly reserved, preventing incomplete stock movements. This improves the accuracy of stock tracking and fulfillment.
Original PR description
Issue ----- When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour. Steps to reproduce ----- - Enable packages - Create a product AAA tracked by SN -…
Issue ----- When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour. Steps to reproduce ----- - Enable packages - Create a product AAA tracked by SN - product category removal strategy set to "Smallest number of packages" - Create a reception for 5 units - Generate serials - Put last line in pack - Confirm reception - Create delivery for 2 units of AAA - Mark as Todo - Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4) - Create a delivery for 3 units of AAA - Mark as Todo > Quantity reserved is one, it only reserved SN 5 Cause ----- The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676 We end up at https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724 The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from. https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705 This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available. This leads to `quants` in `_get_reserve_quantity` containing unavailable quants https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866 This later gets "caught" in `available_quantity` https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897 and the quants don't get reserved a second time thanks to https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914 but this also means the reservation is incomplete. Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676 and avoid the faulty logic. Solution ----- Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91 Our options are: - make the field stored (not stable) - add a search function - filter reserved quants out of `single_item_ids` First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss. ----- Ticket: opw-5972350
This update fixes an issue where closed Helpdesk tickets were sending out emails with the database ticket ID instead of the customer-facing ticket reference. The change ensures all email communications consistently use the correct ticket reference, improving clarity and accuracy for customers. This was a simple fix to a configuration error.
Original PR description
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the…
Steps to reproduce: ------------------------ 1. Install the Helpdesk. 2. Go to Settings → Technical → Sequences and set the next number to 100. 3. Create a ticket and send a message using the "Helpdesk: Ticket Received" mail template; Observe that the correct reference (100) is used. (Open the full composer to use "Load template") 4. Now send a message using the "Helpdesk: Ticket Closed" mail template and Observe that it displays the database ID (e.g., 1) instead of the reference. Cause: ------ `new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly. https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19 However, the `solved_ticket_request_email_template` uses the database ID (`object.id`) instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references in customer communications. related commit: 3ed5273 Solution: --------- Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id` opw-6087466 Forward-Port-Of: odoo/enterprise#113932
This update ensures the o_spreadsheet component within Odoo is running the most recent version. This resolves a bug related to data validation, specifically preserving spaces in spreadsheet values, and improves the overall stability of the spreadsheet functionality. This change impacts users who utilize the spreadsheet module.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1cc3da19f3 [REL] 18.0.65 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4359debd7e [FIX] data_validation: preserve spaces in dv values [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) 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 fixes a bug that prevented users from correctly accessing and scraping component information from purchase orders created by other users. The issue stemmed from incorrect access rights, specifically related to analytic account lines. This ensures accurate data retrieval and reporting for project management workflows.
Original PR description
When scraping the component of a MO created by another user you could get an access error saying you don't have write access on account analytic lines. Steps to reproduce: ------------------- * Install timesheet_grid and project_mrp_account * Create product A, storable * Create product B with a cost of 20 and also storable * Update the available quantity of product B * Create a BoM for product A, it should only require one product B * Update Marc Demo access right and make sure he doesn't have access to any accounting stuff and he has atleast timesheet approver * Create a first MO for 1 product A and produce it * Create a second MO for 1 prodcuct A but just confirm it * Login as Marc Demo and try to scrap the component of the second MO > Observation: You get an access error here https://github.com/odoo/odoo/blob/d98afdc08b46bf458eaa287ea882cc7663286a59/addons/stock_account/models/analytic_account.py#L95 opw-5954989
5 changes
Resolved issues and error corrections
This update resolves a bug where changes to time off types within an allocation didn't trigger necessary validation checks. Previously, updating the time off type didn't prevent the creation of duplicate overtime adjustments. The fix ensures accurate validation and prevents incorrect overtime calculations, improving data integrity.
Original PR description
Steps to reproduce: ------------------------------------- 1. Install `hr_holidays_attendance` module 2. Time off > configurations > Time off types 3. Create new time off type as follows: * Set…
Steps to reproduce: ------------------------------------- 1. Install `hr_holidays_attendance` module 2. Time off > configurations > Time off types 3. Create new time off type as follows: * Set Approval to Approved by time off officer * Change Take time off In to Hours 4. Save the record and enable Deduct Extra Hours 5. Go to Management > Allocations 6. Create new allocation with created time off type and select 'Audrey Peterson' in Employee 7. Try to save record > Validation Error > Discard changes 8. Change time off type to Paid Time Off > add 'Audrey Peterson' > save record 9. Now change Time Off type to Created Time Off type > Save Observation: ------------------------------------- No Validation Error raised, as the employee and time off type are still the same as they were during creating allocation. Issue: ------------------------------------- In `write` method, there was no any check for the employee if it has enough overtime hours when we change Time off type (`holiday_status_id`) to overtime-deductible leave type. Check was only present in the `create` method: https://github.com/odoo/odoo/blob/a95c639db68f98351c7162de58a041a1c0ee13c5/addons/hr_holidays_attendance/models/hr_leave_allocation.py#L39-L49 Solution: ------------------------------------- 1. Create new function for validate overtime and to create adjustment 2. Added that function to `create` as well as in `write` method 3. Prevents creating a duplicate overtime adjustment for an allocation that already has one opw-5937185
This update fixes an issue where product discounts weren't accurately calculated when a customer was associated with a pricelist based on another pricelist. Now, the base price from the pricelist is used, ensuring discounts are displayed correctly for customers using these tiered pricing structures. This improves the accuracy of pricing and customer experience.
Original PR description
A customer that belongs to a pricelist that is based on another pricelist sees the price set on the product as the base price used to display the discount Steps to reproduce: 1. Install eCommerce 2.…
A customer that belongs to a pricelist that is based on another pricelist sees the price set on the product as the base price used to display the discount Steps to reproduce: 1. Install eCommerce 2. Go to Settings > Website > Shop - Products and enable "Advanced price rules" 3. Go to Website > eCommerce > Products, create a new product called "test" with price $1000 and publish it to the website 4. Go to Website > eCommerce > Pricelists and create a new pricelist called "pricelist1" with a price rule with a fixed price of $500 5. Create another pricelist called "pricelist2" with Discount Policy "Show public price & discount to the customer", Selectable enabled and with a price rule with Computation "Formula", Based on "Other Pricelist", Other Pricelist "pricelist1" and Discount "50.00" 6. Open the eCommerce, select "pricelist2" and open the product page of product "test" 7. The base price of the product is $1000, it should show $500 Issue: We always use the product price as the base price to compute the discount on a product page Solution: When a user belongs to a pricelist that is based on another pricelist, use the price set on the base pricelist as base price opw-6122009
This update fixes an issue where signatures were incorrectly duplicated on generated order PDFs after a signed order was modified. Moving forward, signatures will only be printed on documents created directly by the signature process, ensuring accurate and consistent order documentation. This improves the reliability of our sales records.
Original PR description
A signed order can be modified afterward while retaining the signature on the newly generated PDF. After this commit, we will only print the signature on the document generated by the signature itself and not on any generated PDF afterwards. opw-6159170
This update ensures the Odoo spreadsheet component is running the latest version (17.0.91). It includes a fix to preserve spaces in data validation fields, improving the accuracy of spreadsheet data entry. This change enhances the overall stability and usability of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/03d3725dce [REL] 17.0.91 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/03707771eb [FIX] data_validation: preserve spaces in dv values [Task: 5418098](https://www.odoo.com/odoo/2328/tasks/5418098) 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 corrects an issue in the l10n_cz VAT return report, ensuring accurate classification of financial entries. Previously, entries were incorrectly categorized based on amount thresholds. Now, all entries without VAT numbers and those using specific VAT regimes are consistently classified under section A5, regardless of their value.
Original PR description
backport of: 7463184bd3548f0027caf1309707aece3b487d43 Before this commit, the l10n_cz VAT return report classified entries in section A4 if their total amount exceeded 10,000 CZK, and in section A5 if the amount was 10,000 CZK or less. - In l10n_cz, create an invoice with a cz partner without vat, over 10000. - In tax return the entry will be in section A4. With this commit: - Entries with no partner VAT number are now always classified under A5, regardless of the total amount. - Entries using a special VAT regime (l10n_cz_scheme_code), corresponding to Section 89 – travel services and Section 90 – margin scheme) are also always classified under A5, regardless of the amount. opw-4953787