Daily updates from Odoo
Friday, March 20, 2026
211 changes
12 changes
Resolved issues and error corrections
This update resolves a technical issue within Odoo's Studio where view editing sometimes caused errors. The fix ensures that Studio correctly handles inherited views, preventing crashes and improving the stability of the view creation process. This change enhances the reliability of the Studio tool for users.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#110835
This update resolves an issue preventing new employee creation when generating BVG-LLP reports with duplicate monthly data. The fix addresses a technical problem related to how Odoo processes recordsets, ensuring accurate employee creation in Swiss companies using the LPP reporting functionality.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335This update streamlines how Odoo tests handle emoji assets, leading to faster test execution and reduced resource usage. The change allows assets to be cached across test suites, improving overall development efficiency. This work prepares for a future feature that will centralize emoji data management.
Original PR description
Preparation work for an upcoming [emoji loader](https://github.com/odoo/odoo/pull/253078) feature that will ease and centralize the loading and management of emoji data. This PR focuses on making assets caches work accross test suites, and to speed up the processing of some utils to increase performance or to reduce memory consumption. See commit messages for details. - Community: https://github.com/odoo/odoo/pull/253344
This update resolves a technical issue that caused tracebacks in the timesheet assistant when a user lacked an assigned employee within the company. This ensures the timesheet assistant functions correctly for all users, preventing disruptions to time tracking processes. The fix improves stability and usability.
Original PR description
This PR fixes two tracebacks when the current user has no employee in the current company and tries to open either the timesheets assistant or systray Task-6041462
This update corrects a numbering issue in the Vietnamese balance sheet report. Specifically, the order of lines within the 'I. Short-term liabilities' section was adjusted to ensure accurate reporting. This ensures financial reports are presented correctly for Vietnamese businesses using Odoo Enterprise.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a problem in the GSTR report testing process. Previously, tests were incorrectly deleting tax amounts. Now, the system removes taxes from the account move line, ensuring more accurate report calculations and compliance. This resolves a technical issue impacting reporting accuracy.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111198 Forward-Port-Of: odoo/enterprise#105174
This update fixes a technical issue where Odoo would sometimes encounter an error when requesting shipping prices from Sendcloud. Specifically, if Sendcloud didn't respond, Odoo would throw an error. This change prevents these errors, ensuring smoother delivery processing and reducing potential disruptions to order fulfillment.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#111057 Forward-Port-Of: odoo/enterprise#109252
This update resolves an issue preventing power buttons from appearing in Odoo Studio report editors. The fix ensures the necessary configuration for local overlay containers is correctly defined within the Studio wysiwyg instance, improving report customization capabilities. This ensures reports render correctly and consistently.
Original PR description
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own…
Description of the issue: Commit [1](https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec) replaces overlay with localOverlay for the table menu. However, studio uses its own wysiwyg instance and config, which does not define localOverlayContainers, causing a traceback when table_menu accesses this.config.localOverlayContainers.key. Solution: Define localOverlayContainers and its corresponding key in studio’s wysiwyg config. Additionally, adjust the table menu position calculation when the table cell is inside an iframe. Also Before localOverlayContainers was not defined in studio, so power buttons did not appear in studio reports. Now that localOverlayContainers is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250503 Forward-Port-Of: https://github.com/odoo/enterprise/pull/108724 Forward-Port-Of: odoo/enterprise#110273 Forward-Port-Of: odoo/enterprise#109012
This update resolves a performance issue in the Followup Report, which was significantly slower in version 19.1. By reverting to a simpler filtering method, the report now opens much faster, preventing potential cron job timeouts on large databases. This improves the overall efficiency of the reporting process.
Original PR description
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1…
To reproduce the issue, on a large db: - Open the form view of a res.partner - Click on the "Due" smart button, to open the Followup Report ==> The opening of the report takes much longer in 19.1 than it used to in 19.0. This is a problem when processing the followup with the cron, as it can cause it to time out. This situation happens because we now use a subquery computing the partner from the account.partial.reconcile objects linked the the move lines (because the Partner Ledger needs to consider move lines made without any partner as well). in 19.0, a domain on the partner_id field was directly executed, taking hence advantage of the index existing for that field. While this makes sense for the Partner Ledger, it's not relevant for the Followup Report. Indeed, in that report, when filtering on a single partner, we only want to show the open invoices and unreconciled payments made for that partner, so we'll never need to consider the lines without partner. We can therefore use the standard domain on partner_id in that case, like before, solving the perf issue in the meantime. Forward-Port-Of: odoo/enterprise#110966
This update streamlines the new user sign-up experience by removing unnecessary steps in the onboarding tour. This change improves the initial user experience, making it faster and easier for new customers to get started with Odoo Enterprise. The simplification focuses on efficiency and reduces friction for new users.
Original PR description
runbot-238363
This update resolves a validation error occurring when invoices for 'Final Consumers' without VAT/CUIT numbers are submitted to ARCA. The system now correctly handles these transactions by classifying them as 'sigd', sending a null DocNro, and ensuring successful validation, avoiding blocked invoices.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error. Forward-Port-Of: odoo/enterprise#106881
This update fixes an issue in the Spanish balance sheet reports where prior period earnings weren't accurately reflected, potentially leading to incorrect equity totals. The change ensures that all retained and unaffected earnings are included, maintaining consistent and reliable equity reporting.
Original PR description
Description of the issue this commit addresses: The ES balance sheet “prior periods” line only matched code 12, so retained/unaffected earnings posted on other codes were skipped, which could understate or skew equity totals. --- Desired behavior after this commit is merged: The line now includes both accounts with code 12% and accounts of type equity_unaffected, so carried-forward results are always included and equity totals stay consistent. --- task-6047627 Forward-Port-Of: odoo/enterprise#111249
27 changes
Resolved issues and error corrections
This update corrects a bug that was causing incorrect decimal values to be generated in French Intrastat XML reports. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate reporting for French businesses using the Intrastat functionality.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves a technical issue preventing the tour from functioning correctly within the Brazilian localization (l10n_br) module. The fix was necessary due to recent changes in the website's user interface, specifically related to the select menu, which caused a conflict and race conditions within the tour.
Original PR description
Because of the community PR that changes the DOM of the select menu, the tour in this commit crashed. This commit adapts the tour and fixes it as races conditions were still present part-of-task-5935511
This update resolves an error that occurred when creating payments for invoices using the Bacs Direct Debit method. The fix ensures that the system correctly handles scenarios where a company's bank account information is missing, preventing a validation error and ensuring payment processing works as expected.
Original PR description
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the…
Currently, an error occurs when user creates a payment for an invoice. **Steps to Reproduce:** - Install `l10n_uk_bacs` with demo data. - Switch to the `UK company`. - Go to `Journals`, select the `Bank Journal`, and remove the `Bank Account Number`. - Go to `Invoices` and create an invoice by adding an `invoice line` with price greater than zero. - `Confirm` the invoice. - Click `Pay`, select `Bacs Direct Debit` as the payment method, and click `Create Payment`. `ValueError: Expected singleton: res.partner.bank()` This error occurs when creating a payment for an invoice using the Bacs Direct Debit payment method. The constraint check bacs bank account trigger [1], but since the journal has no bank account number, it raises an error here [2]. Similar error also occurs when validating a batch payment [3]. This commit ensures that if the journal has no bank account, or if the bank account is invalid, the system raises the same validation error. In batch mode, it raises a UserError when the account is missing. [1]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_payment.py#L52-L58 [2]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/res_partner_bank.py#L18-L19 [3]: https://github.com/odoo/enterprise/blob/8405155aa94b4f26efb202cbf815e874375a7f49/l10n_uk_bacs/models/account_batch_payment.py#L74 sentry-7259107152
This update resolves a bug where subscriptions would incorrectly revert to an 'In Progress' state after a credit note payment was processed. The fix prevents the reopening of subscriptions when a credit note payment (specifically refunds) is made, ensuring subscription status accurately reflects the payment cycle. This improves subscription management and prevents disruptions.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
This update fixes an issue where multiple email addresses on a contact were being overwritten when creating a helpdesk ticket. The change ensures that all email addresses associated with a contact are correctly captured, improving the reliability of ticket creation. This resolves a potential data loss scenario.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
This update resolves an issue where GS1 barcode filtering would fail due to an incorrect date interpretation. The fix prevents errors from blocking product filtering, ensuring accurate internal transfer operations. This improves the reliability of our inventory management system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update fixes an issue where subscription products weren't displaying prices with tax, even when the website setting was enabled to show tax-inclusive prices. The fix ensures that the correct tax rates are applied based on the customer's company, resolving a discrepancy in how product company IDs were being evaluated. This ensures accurate pricing for all subscription customers.
Original PR description
subscriptions Despite enabling the website setting to display tax-inclusive prices, subscription products show prices without tax when a recurring pricelist is configured. In `_get_sales_prices`, the product’s company ID is compared to the website’s company, but products visible to all have a false company ID, and products assigned to a parent company retain the parent’s company ID. As a result, when the product’s company ID does not match the website’s company ID, no taxes are applied.Instead, _filter_taxes_by_company should be used to determine whether the company can access the product’s tax_id. opw-5222411 Forward-Port-Of: odoo/enterprise#102102 Forward-Port-Of: odoo/enterprise#100662
This update resolves a problem where incorrect invoice folio numbers (starting with negative signs) were being generated when no Chilean Fiscal Authorization File (CAF) was configured. The fix ensures that folios are correctly generated based on available CAF numbers, preventing sequence corruption and costly database retries. This improves invoice accuracy and stability for Chilean users.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update resolves a technical issue that caused a traceback when using the pivot table autofill feature. The fix corrects a misidentification of the function being called, ensuring consistent behavior with vertical autofills. While the core autofill functionality remains unchanged, this resolves a potential error.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110994 Forward-Port-Of: odoo/enterprise#109620
This update optimizes the database by removing unnecessary default values from company and partner records. This change reduces data storage and improves performance, particularly for businesses managing multiple companies with different fiscal settings. The fix also resolves a previous issue causing cron jobs to fail.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129 Forward-Port-Of: odoo/enterprise#105917
This update resolves an issue where generating financial reports (FAIA) for Luxembourg companies using multi-currency vendor bills resulted in errors. The fix ensures the necessary currency information is included in the report template, allowing for accurate reporting of sales and purchase taxes. This improves the reliability of financial data for Luxembourg businesses.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update resolves an issue where payrun calculations were failing when an employee's contract started mid-period. The fix ensures accurate integration factor calculations for new hires with staggered contract start dates, preventing incomplete payrun generation. This improves payroll accuracy for new employees.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#110568This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to ensure the map always displays correctly, regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update resolves an issue where the bulk payments feature would crash if a bank journal wasn't properly connected. A new user message has been added to alert users when a journal isn't linked to a bank, preventing the error and improving the user experience.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/c9cc89f58f7d98396afac3bdacfeff9b00a02a21 introduce the initiate bulk payments feature. When selecting a batch you can also check the status of this batch. But for the moment, if you select a batch that is not connected to a bank, the action will traceback with a redirect. This commit will add a user error to warn the user than the journal needs to be connected to a bank. task-6009083 Forward-Port-Of: odoo/enterprise#111031 Forward-Port-Of: odoo/enterprise#109956
This update ensures that the tax returns journal is automatically translated into all supported languages, rather than just the user's language. This improves the accuracy and usability of the tax reporting feature for international users.
Original PR description
Currently, the tax returns journal is created in the code and not via the standard `@template` function that makes sure it is always translated in the installed languages. So for now it was only translated in language of the current user. We refactored the code so the journal gets created via the standard `@template` function and thus automatically gets translated into all the installed languages. task-5921458 Forward-Port-Of: odoo/enterprise#111126 Forward-Port-Of: odoo/enterprise#107465
This update corrects a bug in the demo data for our Odoo Enterprise system. Specifically, it ensures that leave allocations are correctly created when using 'faketime,' which simulates future dates. This prevents errors related to time off calculations and ensures accurate reporting for all users.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690
This update corrects a potential issue where calculations for employee payslips were unintentionally impacting a large number of records. The change now limits the calculation to active payslips, ensuring accurate and reliable payroll processing. This improves data integrity and reduces the risk of errors.
Original PR description
Before this commit, `_compute_basic_net` was not limited to specific payslips, potentially affecting thousands of records and even more of `hr.payslip.line` records. This commit restricts the compute to ongoing payslips. task-6022499 Forward-Port-Of: odoo/enterprise#110069
This update resolves an issue preventing new employee creation when generating BVG-LLP reports. The fix addresses a technical problem with how Odoo compares report data, ensuring the system correctly handles multiple reports with the same month.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335This update resolves a potential issue where the system couldn't correctly evaluate data within project tasks. The fix ensures that all data used in evaluation processes are treated as strings, preventing errors and improving data integrity. This ensures reliable operation of the industry_fsm module.
Original PR description
literal_eval needs string values to evaluate,
action.get('domain', []) returns non-string value.
Forward-Port-Of: odoo/enterprise#111202This update corrects a problem in the GSTR report testing process. Previously, tests were deleting tax lines, which caused inaccurate reporting. Now, the system correctly removes taxes from the account move line, ensuring accurate GSTR report calculations and compliance.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111198 Forward-Port-Of: odoo/enterprise#105174
This update corrects an issue with the numbering of report lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was adjusted for improved clarity and accuracy. This ensures the report aligns with Vietnamese accounting standards.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a technical issue where Helpdesk ticket buttons weren't being properly recognized by the system's editor. The change ensures buttons within email templates function correctly, preventing links from appearing as buttons. This improves the user experience when interacting with tickets.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#110797 Forward-Port-Of: odoo/enterprise#107888
This update fixes an issue in the Spanish (ES) balance sheet reports where retained earnings were incorrectly excluded. Now, all relevant equity adjustments are accurately reflected, ensuring consistent and reliable equity totals. This improves the accuracy of financial reporting for Spanish businesses using Odoo Enterprise.
Original PR description
Description of the issue this commit addresses: The ES balance sheet “prior periods” line only matched code 12, so retained/unaffected earnings posted on other codes were skipped, which could understate or skew equity totals. --- Desired behavior after this commit is merged: The line now includes both accounts with code 12% and accounts of type equity_unaffected, so carried-forward results are always included and equity totals stay consistent. --- task-6047627 Forward-Port-Of: odoo/enterprise#111249
This update corrects a visual discrepancy in the AI Live Chat snippet's appearance, ensuring it matches how it's displayed in real-time. The issue stemmed from mismatched code structures, and this fix ensures a consistent user experience across different devices and configurations. It also resolves a related problem with the fallback button visibility.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update corrects a technical issue where archived partner data was incorrectly being matched during bank statement retrieval. Now, the system only considers active partners when finding bank statements, ensuring accurate partner assignments and data integrity. This improves the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#111029 Forward-Port-Of: odoo/enterprise#110446
This update resolves a validation error occurring when invoices for 'Final Consumers' in Argentina lack a VAT/CUIT number. The system now correctly sends a 'null' value for the DocNro field, aligning with ARCA's requirements and preventing invoice rejection. This ensures compliance and smooth processing of these transactions.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…
**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error. Forward-Port-Of: odoo/enterprise#106881
This update corrects a problem where the company logo was appearing too large on various Odoo reports. The fix targeted a generic CSS selector that was unintentionally affecting multiple reports. This ensures a consistent and professional appearance for all generated reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432 Forward-Port-Of: odoo/enterprise#110858
6 changes
Resolved issues and error corrections
This update resolves an issue impacting VAT calculations for Peru (PE) invoices. A previous change removed a key element needed for accurate tax tier determination, leading to incorrect tax amounts. This fix reintroduces the necessary 'TierRange' setting, ensuring proper VAT calculations are generated for PE invoices.
Original PR description
In [^1] the PE implementation for XML generation was rewritten to use the new dict_to_xml design rather than a large QWeb view. In that refactor the `TierRange` key on `TaxCategory` was lost. This PR re-introduces it. task-6046603 [^1]: odoo/enterprise#87598
This update resolves a technical issue related to how Odoo processes bank statement imports with multiple currencies. Specifically, it prevents a 'singleton error' that occurred when fetching CODA data, ensuring accurate journal matching and import functionality for businesses using multiple currencies.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111250 Forward-Port-Of: odoo/enterprise#111101
This update corrects an issue with the numbering of lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was incorrect. This ensures the report accurately reflects financial data for Vietnamese businesses using the Odoo Enterprise system.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update fixes a user experience issue where the 'Generate PDFs' button didn't process all employee declarations when multiple pages were involved. Now, selecting 'Select All' reliably generates PDFs for all records in the list, and users can easily regenerate PDFs for existing documents. This ensures a smoother and more intuitive process for generating payroll reports.
Original PR description
This PR solves the following issues: - In the list view of employee declarations, when the records span to multiple page, pressing `Select all` and the `Generate PDFs` button only generates the PDFs of the records selected on the current page, which is confusing for users who expect all records to be processed. - When you select lines that have a generated PDF, you should have an option to regenerate the PDF if needed. At the moment, the Generate PDFs button only works on lines in draft state. task-5909426 Forward-Port-Of: odoo/enterprise#107232
This update fixes an issue where quarterly VAT returns in the Italian tax module didn't automatically generate the necessary XML files. The fix corrects a logic error that was relying on the wrong date field for determining the return period. Now, quarterly returns will correctly produce the XML files required for submission.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544 Forward-Port-Of: odoo/enterprise#108548
This update resolves a test issue where simultaneous data synchronization in the POS tax module caused errors. The fix ensures that backend calls complete before the test continues, improving test reliability and preventing disruptions. This enhances the overall stability of the POS tax functionality.
Original PR description
In the test test_pos_avatax_flow, two calls are made to get_order_tax_details almost simultaneously, which causes the second call to raise an error due to both call trying to sync the same order at the same time. This commit fixes the test by waiting for the backend calls to be done before proceeding with the test next steps. runbot-error: 238871, 238872 Forward-Port-Of: odoo/enterprise#110341
9 changes
Resolved issues and error corrections
This update fixes an issue where consolidated POS invoices were incorrectly showing a zero Total Amount Payable due to pre-payment mapping. The change ensures that the payable amount accurately reflects the total invoice amount, as required by the MyInvois tax officer and helpdesk. This ensures proper integration with the MyInvois API.
Original PR description
For POS consolidated invoices, the PrePayment Amount was mapped to the payment linked to the document. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document , regardless of prior payments. This commit forces the PaidAmount to 0 for consolidated documents, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-[6021698](https://www.odoo.com/odoo/all-tasks/6021698) Forward-Port-Of: odoo/odoo#253499
This update corrects a bug where compensation account move lines weren't created for dropshipped products when the purchase price differed from the bill price. The fix ensures accurate accounting for these discrepancies, preventing valuation errors and ensuring proper financial reporting. It addresses a logic issue related to how account move lines are generated for dropship invoices.
Original PR description
**Problem:** compensation amls are not created for dropshipped products when there is a difference between the price of the PO and the price on the bill **Context:** For non dropship avco real time…
**Problem:** compensation amls are not created for dropshipped products when there is a difference between the price of the PO and the price on the bill **Context:** For non dropship avco real time products: When you create a PO for a product @ 10 - stock interim received is credited of 10 - stock valuation is debitted of 10 And you then validate a bill for a price of 8 - stock interim received is debitted of 8 - account payable is creditted of 8 This leaves stock interim received with credit of 2 and stock valuation is over valued by 2. So we create 2 extra account move lines - One debit of 2 for stock interim received - One credit of 2 for stock valuation (or Expenses if the product is not in stock anymore because then it's the expense account which was over valuated) nb: if the product is still in stock those 2 lines are created via stock valuation layer In the case of a dropshipped product, the product is not in stock anymore so it should be creditting expense, but no extra amls are created at all. **Steps to reproduce:** - enable the "dropshipping" and "anglo saxon accounting" settings - create a storable product with avco automated category - in the inventory tab, select the dropship route - in the purchase tab, set a vendor - create and a confirm a quotation for this product - on the linked purchase order, set a unit price of 10$ and confirm - validate the dropship move - create a bill for the purchase order - set the price to 8$ and confirm - navigate to journal items and search for your product **Current behavior:** no compensation account move lines were created **Expected behavior:** 2 account move lines should have been created: - One debitting 2 in stock interim received - One creditting 2 in expense **Cause of the issue:** *the following logic was introduced by* https://github.com/odoo/odoo/pull/126536 to create those extra amls and layers, _apply_price_difference() is called inside _post() https://github.com/odoo/odoo/blob/32408a8dea43f57bba1a56c775ae228131720749/addons/purchase_stock/models/account_invoice.py#L129 There we have 2 problems : Problem 1: When fetching the layers linked to the account move line, we fetch both the incoming and the outgoing valuation layers because they are both linked to the dropship move. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L46 But we only want the incoming layer because the outgoing layer should not interfere with the bill. nb: In a standard case like the one of the steps to reproduce, it would work to leave both layers, but : - it works for the wrong reasons : the quantity of the aml would first be consumed on the incoming layer and nothing would happen with the second layer as the quantity of the incoming layer is the same as the one of the aml. - it would probably break in more complex use cases. So it feels unnecessarily risky to leave it like that. Problem 2: Inside _generate_price_difference_vals we call _replay_history which returns two values that are assigned to two variables. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L82 The second variable, layers_and_invoices_qties is a default dict which keys are tuples (layer L, invoice I) mapped with [the initial quantity invoiced by I on L, the remanining qty invoiced by I on L] (here 'remaining' is related to invoice and has nothing to do with stock qties) https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L168-L171 So in our very basic use case, with a single invoice and a single layer, we should have a key (our layer, our invoice) linked to the value [1,1]. But this key is not in the dictonary. *The reason is the following :* inside _replay_history the parameter "history" contains the layers and the amls (in our case 1 layer and one aml which is self). Each layer is added to qty_to_invoice_per_layer https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L177-L178 https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L191-L192 Then, for each aml: the layers are added to layer_to_consume, alongside their remaining quantity. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L215-L221 And for each layer which has a quantity billed by the invoice, a key is added to layers_and_invoices_qties https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L222-L231 In our case, the move linked to the layer is the dropship move so _is_in() will be false and the layer won't be added to layers_to_consume. https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L220-L221 So the key will not be created. *The consequence is the following:* Later in _generate_price_difference_vals() we acces the value of this key (the key that should be there (layer, invoice)) https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L91 to get the invoiced qty which will later be used to determine which quantity is still in stock and which is out of stock (giving us the quantities for the compensation layers and amls) but as the key does not exist, invoicing_layer_qty will have a value of 0 so we will exit the loop and no amls or svls will be created https://github.com/odoo/odoo/blob/455b289abd691ccb274dfce43c1b4347add20a41/addons/purchase_stock/models/account_move_line.py#L92-L93 opw-5498878 Forward-Port-Of: odoo/odoo#253298
This update resolves a visual issue where the star rating element on product reviews was hidden behind other elements. The fix adjusts the star rating's placement within the email composer to ensure it's correctly displayed without overlapping other content. This improves the user experience for customers leaving reviews.
Original PR description
# How to reproduce - Go to the eCommerce page of any product - In Edit mode, in the Customize tab, enable reviews - Scroll down and click on the "+" button next to reviews # The problem The star…
# How to reproduce
- Go to the eCommerce page of any product
- In Edit mode, in the Customize tab, enable reviews
- Scroll down and click on the "+" button next to reviews
# The problem
The star rating element is squished / hidden behind other elements of the review
# Why
The star rating element is added to the mail composer element as follows :
```xml
<t t-inherit="mail.Composer" t-inherit-mode="extension">
<xpath expr="//div[hasclass('o-mail-Composer-coreMain')]" position="before">
<div t-if="env.displayRating and !message" class="o-mail-Composer-starCard d-flex">
```
The composer element has the display: grid attribute with different grid-areas defined :
```scss
.o-mail-Composer {
grid-template-areas:
"sidebar-header core-header"
"sidebar-main core-main"
"sidebar-footer core-footer";
grid-template-columns: auto 1fr;
grid-template-rows: auto 1fr auto;
```
But, o-mail-Composer-starCard does not define any grid-area, so the star rating element fills the grid in the first space available that is not already taken. That space used to be core-header, which worked totally fine, but this commit (https://github.com/odoo/odoo/commit/451c2c9) made it so the composer element always has a div in the core-header area. This made it so there was no available space for the star rating element (since core-header was taken) and so it defaulted to a position in the center of the composer.
Since there is now always a div element in the core-header area, this fix change the xpath of the star-rating so that it is put inside of that div.
opw-6046551
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update corrects a bug where changes to view ordering within the Odoo Studio were not consistently applied. The fix involved updating the default order setting within the documents module to use the correct attribute on the relational model, ensuring that view order changes are now properly reflected.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111091
This update corrects a numbering issue in the Vietnamese balance sheet report. Specifically, the order of report lines within the 'I. Short-term liabilities' section has been fixed. This ensures accurate and consistent reporting for Vietnamese businesses using the Odoo Enterprise system.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update resolves a layout issue caused by a recent change intended to prevent unwanted clicks in the FileUploader. The fix ensures the UI remains properly aligned and functional, specifically addressing a problem where edition buttons were misaligned during file uploads. This improves the user experience for HR and employee data management.
Original PR description
This PR completes the changes introduced in: https://github.com/odoo/odoo/commit/2cbb735f5eecb7c31db8245b8d598d7193992a05 ### Issue: A `<div>` was added to prevent click propagation in the FileUploader, but it introduced unintended extra spacing in several parts of the UI ### Cause: The added `<div>` affected the layout by taking up space where it should not ### Fix: A specific class is added to neutralize the layout impact of this element while preserving the click propagation behavior ### Steps to reproduce: - Install `hr' - Create a new Employee - Go in Private Information > Work Permit - Upload a file Before the fix, the edition's buttons are in another line opw-5918379
This update corrects a bug that was causing incorrect leave calculations within the holiday accrual process. The previous code used an inconsistent field, leading to potential errors and inaccurate leave balances. This fix ensures accurate leave accruals and prevents future issues.
Original PR description
## Issue Oblivion regarding community-239836 The field `leaves_taken` (which shouldn't be accessed from the `_process_accrual_plans` method because it is inconsistent/can lead to infinite loop, see the related PR explanation) is used instead of the variable `leaves_taken`. robodoo up to saas-18.4 included Forward-Port-Of: odoo/odoo#253076
This update ensures that presence status notifications are sent only after a user's presence record is removed from the system. Previously, notifications were sent with outdated information, leading to incorrect status updates. This fix guarantees accurate and reliable presence status broadcasts for users.
Original PR description
Before this commit, presence channel notifications for unlinked records were sent before the records were actually removed from the database. This caused `im_status` to be calculated using stale data, occasionally resulting in statuses other than "offline" being broadcast. This commit ensures notifications are sent only after the presences have been unlinked, guaranteeing an accurate status. Forward-Port-Of: odoo/odoo#254186 Forward-Port-Of: odoo/odoo#249314
This update brings the latest version of the spreadsheet component to Odoo 18.3. It addresses several minor bugs and improves functionality, specifically related to pasting values, chart data, and pivot table features. These changes ensure a smoother and more reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6626b4649d [REL] 18.3.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6626b4649d [REL] 18.3.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/62a1fd4307 [FIX] clipboard : paste as value [Task: 5936382](https://www.odoo.com/odoo/2328/tasks/5936382) https://github.com/odoo/o-spreadsheet/commit/09873f6c22 [FIX] Chart: Update geojson data [Task: 5224009](https://www.odoo.com/odoo/2328/tasks/5224009) https://github.com/odoo/o-spreadsheet/commit/4d29b1d901 [FIX] charts: hierarchical charts should show formatted labels instead of raw [Task: 5913296](https://www.odoo.com/odoo/2328/tasks/5913296) https://github.com/odoo/o-spreadsheet/commit/d901f29b3f [FIX] pivot: can add the same granularity [Task: 5949522](https://www.odoo.com/odoo/2328/tasks/5949522) 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>
8 changes
Resolved issues and error corrections
This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to ensure the map always displays correctly, regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update resolves a technical issue that could have caused errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant process from triggering, ensuring smoother and more reliable import of bank statement data, particularly for businesses operating with diverse currency setups.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111101
This update corrects a technical issue that caused the Odoo Enterprise system to crash when resetting purchase data fetching settings for a company. The fix ensures that the system correctly handles this scenario, preventing future errors and maintaining reliable data retrieval for Kenyan e-invoicing.
Original PR description
In case the purchase last fetch data is resetted to `False` on the company, the next cron run will crash with: `type object 'datetime.datetime' has no attribute 'datetime'` This commit fix the wrong default date fallback. opw-5220129 Forward-Port-Of: odoo/enterprise#111124
This update resolves a technical issue related to how geographic data (topoJSON) is processed within the Enterprise edition of Odoo. The fix ensures that charts displaying location-based data are now rendered correctly, improving the accuracy and reliability of these visualizations. This primarily impacts users relying on charts that utilize geographical information.
Original PR description
test adaptation Counterpart of github.com/odoo/odoo/pull/248847 Task-5224009
This update corrects a bug where changes to view order within the Documents module's studio interface weren't consistently applied. The fix involved updating the default order setting within the Documents relational model, ensuring that view order changes are correctly reflected. This improves the user experience for managing document views.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024 Forward-Port-Of: odoo/enterprise#111091
This update fixes an issue with the numbering of lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was corrected. This ensures the report accurately reflects financial data for Vietnamese businesses using the Odoo Enterprise system.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a visual issue where the company header in accounting reports appeared grayed out in dark mode. The change ensures consistent color styling across both light and dark themes by updating the header's color to a standard muted data color, improving the user experience.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#110108
This update resolves a discrepancy in accounting calculations within the Point of Sale (POS) module for Mexican tax reporting (l10n_mx_edi_pos). Previously, asset loading issues resulted in incorrect amounts being displayed. This change ensures that POS transactions accurately reflect the calculations performed in the main Python accounting system.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5970322 Forward-Port-Of: odoo/enterprise#111266
19 changes
Resolved issues and error corrections
This update fixes an issue where errors in PDF generation would halt the entire batch, preventing regeneration. Now, individual PDFs with errors can be regenerated, and the 'Generate PDFs' button works correctly when 'Select All' is used, streamlining the payroll report process.
Original PR description
**Current behavior before PR:** When the PDFs are processed, they are in batch of max(batch_size,30) by the scheduled actions, if one of the PDFs is in error, the whole batch will not be generated and it will be put in draft. Also, when you select lines that have a generated PDF, you do not have the option to regenerate them. **Desired behavior implemented in this PR:** When a PDF is in error, it should not affect the other ones of the batch. Also, you can now select lines with generated PDFs and have the option to regenerate them if needed. This PR also fixes the following UX issue associated with the generation and posting of the PDFs in the employee declaration list view: - The two buttons "Generate PDFs" and "Post PDFs" were working only on the selected records in the current page, even if the user clicked on "Select All" button. task-5909426
This update optimizes the database by removing unnecessary default values from company and partner records. Specifically, the automatic setting of branch codes and purchase date defaults has been removed for multi-company environments, reducing data storage and improving performance. This change ensures that each company's data is accurate and efficient.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129 Forward-Port-Of: odoo/enterprise#105917
This update resolves a problem where generating VAT reports (FAIA) for invoices in different currencies caused errors. The fix ensures the necessary currency information is included in the report template, allowing accurate VAT calculations for Luxembourg companies. This improves the reliability of financial reporting.
Original PR description
Steps to reproduce 1/ setup a LU company. The default company currency will be EUR. 2/ create a vendor bill in another currecy (e.g. USD) 3/ take note of the bill date and accounting date (ideally set them in the past, like 1 month) 4/ generate the FAIA report for the period containing the created bill => error while rendering the qweb template The core of the error is when rendering the l10n_lu saft template. Sales invoices and purchase invoices reuse the standard `account_saft.tax_information` report, which expects to find `currency_code` in the object's fields. This commit explicitly re-adds it when creating the document's tax summary. opw-5216057 Forward-Port-Of: odoo/enterprise#110660 Forward-Port-Of: odoo/enterprise#106902
This update resolves a problem preventing users from successfully connecting their expense accounts via Stripe. The issue occurred when users attempted to connect through the expense settings, specifically by accepting the terms of service and clicking the 'Connect' button. This fix ensures seamless integration for expense reporting.
Original PR description
To reproduce: - Install hr_expense_stripe_demo - Open the expense Settings - Accept the TOS - Click on Connect (demo)
This update resolves an error that occurred when setting an accounting period for Dutch companies using the l10n_nl_reports module. The fix corrects a mistake in how tax tags were being retrieved, preventing a traceback and allowing users to successfully create accounting periods. This ensures accurate reporting for Dutch businesses.
Original PR description
Creating an accounting period for a Dutch company raises a traceback. Steps to reproduce the error: - Install ``l10n_nl_reports`` and ``accountant`` module with demo data - Switch to NL Company - Go to Accounting > In Tax Returns > Click Set Periods > Set Opening Date > Apply Traceback: ```py 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report' ``` https://github.com/odoo/enterprise/blob/f23c592a933d7e5e5745aea60d0dcc5738249580/l10n_nl_reports/models/account_return.py#L20 In commit [1], Here, ``_get_tax_tags_for_nl_sales_report()`` method is called instead of ``_get_ec_sales_tax_tags()``. which leads to the above traceback. [1]:https://github.com/odoo/enterprise/commit/0a0fa0dae918ec5198a019a3e5be71a919f0e7c6 sentry-7340518330 Forward-Port-Of: odoo/enterprise#110948
This update corrects a technical issue in the Account Avatax module, ensuring that company-specific settings are accurately identified. Previously, a key piece of information was missing, which has now been added to improve the module's functionality and data accuracy. This ensures proper tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update fixes an issue where multiple email addresses on a contact were being overwritten when creating a helpdesk ticket. The change ensures that all email addresses associated with a contact are correctly captured, improving the reliability of ticket creation. This was caused by a technical limitation in how email addresses were handled, and the fix simplifies the process.
Original PR description
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce:…
Prerequisites: ------------------------------ 1. Set up incoming mail server with Create a New Record set to Helpdesk Ticket 2. From Settings, create one Alias Domain Steps to reproduce: ------------------------------ 1. Install Helpdesk module 2. Open Helpdesk Team > Settings 3. Inside Channels, Set the mail used for the incoming server and the alias created 4. Set Accept Emails From to Everyone 5. Create a new contact with multiple emails (eg: `a@b.com`, `c@d.com`) 6. From Fiest mail (eg: `a@b.com`), Send one mail to mail set in the helpdesk team alias mail. 7. Open Incoming mail sever > Click on Fetch Now 8. Open Created Contact Observation: ------------------------------ The contact's email field is overwritten. The second email address (e.g. `c@d.com`) is lost Issue: ------------------------------ After `create`, since `partner_email` was stored with a value that differs from `partner_id.email`, the inverse method `_inverse_partner_email` kicks in. This is where `_get_partner_email_update()` is called. In `_get_partner_email_update()` `tools.email_normalize()` only handles a single email. When the partner has multiple email, the normalization keeps both, while the ticket email normalizes to just have one mail. The strict `!=` comparison fails, triggering the unwanted update. https://github.com/odoo/enterprise/blob/7c23efafe368787c858db31cec075f642ae6715b/helpdesk/models/helpdesk_ticket.py#L363-L369 Solution: ------------------------------ Instead of comparing the full normalized strings, we should check whether the ticket's normalized email is contained within the set of the partner's normalized emails Note for reviewer ----------------------------- After discussion with the PO (LNA), his opinion is that having multiple email addresses in a single field is not a good practice. This use case is only semi-supported in Odoo, it may work in some cases, but it is not reliable. The recommended approach is to create separate contacts for each email address. That said, we should also avoid automatically clearing or altering the existing value in the field. Based on this, I have implemented a minimal fix that prevents altering the existing value in the field. I am leaving it up to the review to decide whether this fix is worth keeping from a technical standpoint. opw-5478067 Forward-Port-Of: odoo/enterprise#107808
This update resolves an issue preventing new employee creation when generating BVG-LLP reports. The fix addresses a technical problem with how Odoo compares report data, ensuring accurate employee record creation. This improves the reliability of payroll processing for Swiss companies.
Original PR description
Steps to reproduce: ---------------------------------- 1. Install `l10n_ch_hr_payroll_elm_transmission` module 2. Switch to Swiss company 3. Navigate to Payroll > Transmission > BVG-LLP Basis…
Steps to reproduce:
----------------------------------
1. Install `l10n_ch_hr_payroll_elm_transmission` module
2. Switch to Swiss company
3. Navigate to Payroll > Transmission > BVG-LLP Basis Declaration
4. Create two Reports with same Year and Month
5. Now try to create new Employee from the employee app
Observation:
----------------------------------
Tracaback Occurs:
```
File '/home/odoo/src/enterprise/19.0/l10n_ch_hr_payroll/models/l10n_ch_employee_monthly_values.py', line 319, in _compute_bvg_lpp_annual_basis
existing_declaration = max(existing_declaration, key=lambda r: r.month) if existing_declaration else False
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File '/home/odoo/src/odoo/19.0/odoo/orm/models.py', line 5934, in ensure_one
raise ValueError('Expected singleton: %s' % self)
ValueError: Expected singleton: l10n.ch.lpp.basis.report(1, 2)
```
Issue:
----------------------------------
In the following code:
https://github.com/odoo/enterprise/blob/44a26539093f9313d9cd5f823c11866e3c98ec97/l10n_ch_hr_payroll_elm_transmission/models/l10n_ch_employee_monthly_values.py#L319-L320
Python's max() function doesn't just call the key function once per item. When there are ties (equal key values), it may need to compare the original objects, and during this process, Odoo's recordset operations combine records, causing the lambda receives `r` as a combined recordset. To access `.month` on a multi-record recordset it gives singleton error.
Solution:
----------------------------------
Creates tuples of (month, recordset) pairs and uses max() to compare month integers directly, avoiding the singleton error.
opw-5391742
Forward-Port-Of: odoo/enterprise#111084
Forward-Port-Of: odoo/enterprise#102335A recent update to the document layout, including VAT information, caused a test to fail. This fix addresses a problem where the test's editor selection wasn't correctly updated after adding the VAT block, preventing a key feature from working. The update ensures the test now passes, guaranteeing correct VAT display functionality.
Original PR description
Issue The test `test_edit_header_only_company` was failing after updating the document layout to include the VAT block in the company address section. Cause Adding the VAT line modified the DOM structure of the header layout. The tour step inserting the placeholder span no longer correctly set the editor selection, preventing the powerbox from opening and causing the test to fail. Solution Update the tour to explicitly reset the editor selection after inserting the span so that the powerbox can open correctly. opw-5373374 Related Community PR : https://github.com/odoo/odoo/pull/249225 Forward-Port-Of: odoo/enterprise#109924
This update ensures that follow-up emails for invoices now send the actual invoice PDF, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDFs, ensuring accurate and consistent invoice reminders are sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#111085 Forward-Port-Of: odoo/enterprise#98820
This update resolves a technical problem within Odoo's web studio that prevented users from correctly editing views, specifically when using inherited views. The fix ensures that the studio accurately recognizes and incorporates inherited views during the view creation process, preventing errors and crashes. This improves the stability and usability of the web studio.
Original PR description
This commit is a followup to odoo/enterprise#94747 which was made incomplete by odoo/enterprise@52f27c4. Sometimes actions set one of their view to an inherited view rather than the primary. This created traceback because the to-be-created studio arch was normalized against the inheritance tree without the given inherited view, which is wrong. After this commit, there is no crash. opw-5955734 Forward-Port-Of: odoo/enterprise#111245 Forward-Port-Of: odoo/enterprise#110835
This update fixes an issue with the numbering of lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was corrected. This ensures the report accurately reflects financial data for Vietnamese businesses using Odoo Enterprise.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111335 Forward-Port-Of: odoo/enterprise#111234
This update corrects a visual issue in the partner ledger report where overdue invoices and negative amounts weren't consistently displayed with the correct color (red and blue, respectively). The fix ensures that key financial information is clearly highlighted, improving report readability and accuracy for users reviewing their accounts. This improves the user experience when analyzing overdue invoices.
Original PR description
commit introducing the issue: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 Steps to reproduce: - open the partner ledger with some one overdue invoice -> The expected result should be to see the due date in red. -> Negative amounts in the partner ledger should be displayed in blue as well. Forward-Port-Of: odoo/enterprise#111295
This update corrects a problem where text fields in Odoo Sign's PDF forms were incorrectly displayed as checkmarks. The issue stemmed from an error in how the system interpreted PDF tags, specifically when standard text fields had appearance settings. This change ensures that text field values are correctly rendered in signed documents.
Original PR description
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often…
Create an interactive PDF form in Adobe Acrobat containing a standard Text Field (/FT /Tx). - Fill the text field with a value (e.g., "John Doe") and save the PDF. - (Note: Adobe Acrobat will often automatically assign an Appearance State (/AS /N) to this text field). - Upload this PDF to the Sign app. **Current behavior:** The text field's string value is ignored and replaced with a checkmark (✓). **Expected behavior:** The text field should correctly render the string value that the user entered. **Cause of the issue:** In the _draw_field_value function, the parser checks if an /AS (Appearance State) tag exists and is not set to /Off. If true, it assumes the field is a checked box and draws a chr(0x2713). However, it fails to check the Field Type (/FT) first. Because Adobe Acrobat sometimes assigns /AS tags to standard Text Fields (/FT /Tx), we misinterprets these populated text fields as checked buttons. **Solution:** This PR fixes the issue safely for stable versions across two commits: [REF]: Extracts the value extraction logic into a dedicated _get_field_value helper method to allow isolated unit testing without requiring a canvas or physical PDF files. No behavioral changes in this commit. [FIX]: Wraps the /AS check within an if field_type == "/Btn": condition. This ensures only actual Checkboxes and Radio Buttons render as checkmarks, allowing Text Fields to fall through and properly return their /V string values. Task: 6018260 Forward-Port-Of: odoo/enterprise#110865 Forward-Port-Of: odoo/enterprise#110292
This update resolves an issue where Odoo would display an error message if Sendcloud didn't respond with shipping price information. The fix prevents a program crash by gracefully handling the situation where Sendcloud doesn't provide a response, ensuring a smoother user experience.
Original PR description
Sendcloud sometimes doesn't respod when asking for `shipping-price`. So when we try to retrieve the first element of the response, we raise an `IndexError`. ----- Ticket: opw-5951749 Forward-Port-Of: odoo/enterprise#111057 Forward-Port-Of: odoo/enterprise#109252
This update resolves an issue where the attendance Gantt chart incorrectly displayed employees without contracts, leading to inaccurate reporting. The change ensures these employees are not shown in the Gantt view, aligning with the system's requirement that only employed staff can record attendance.
Original PR description
In a recently created database, the attendace gantt chart hides all hours of the day, as an employee with no contract is considered unavailable at all times. This commit will make employees with no contract act as if they were in a flexible calendar (only for the gantt view of course). task-5222648
A technical error preventing a test process (runbot) from correctly evaluating overtime rules was resolved. The update corrected the tour's triggers to align with the current system, ensuring accurate overtime calculations and preventing disruptions to payroll processing.
Original PR description
The tour for the overtime ruleset flow was failing in the runbot because some of the triggers do not exist in the view. Updated the tour to use the correct triggers for each action. Task: 6053589
This update ensures that Sales Orders generated from Field Service timesheets only assign a salesperson to the order when the technician has Sales or Invoicing access. Previously, technicians without these permissions were incorrectly assigned as salespeople, leading to unwanted invoice notifications and follower assignments. This change improves data accuracy and reduces unnecessary communication.
Original PR description
Before this commit: - - With the Field Service and Planning integration, validating a planning shift linked to a Field Service project could generate a Sales Order from timesheets and materials. - The user linked to the resource was always assigned as salesperson on the generated Sales Order. - When that user had no Sales or Invoicing access, they were still set as salesperson, causing them to be added as followers on invoices and receive billing-related notifications. After this commit: - - The salesperson is assigned on the generated Sales Order only when the assigned user has Sales or Invoicing access. - If the user lacks these access rights, the salesperson field is left empty, preventing technicians from being added as invoice followers or receiving billing-related notifications. task-5023095
This update resolves issues with timesheet reminder emails displaying incorrect week dates and failing to open the correct grid view. The fix ensures that reminder emails accurately reflect the correct week and that clicking the email directs users to the appropriate timesheet grid.
Original PR description
Issues: - Reminder emails were showing the wrong week dates. - Opening a timesheet from the reminder email did not go to the correct grid view(scale). All the above issues are fixed in this commit. task-3624610
6 changes
Resolved issues and error corrections
This update adjusts how Odoo automatically refreshes GST tokens, moving from a scheduled 5-hour interval to a permanent manual trigger. This change ensures compliance and reduces the risk associated with automated token updates. The process is now controlled by specific actions within the application.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time.
This update resolves an issue where payslips for former employees were failing to calculate unpaid hours correctly. The change ensures that version history is accessed properly even after an employee is archived, allowing accurate calculation of worked hours for final paychecks. This was driven by a related change in the Odoo community.
Original PR description
Before this commit, when the user creates a payslip for an employee who left the company to pay him the remaining hours worked unpaid, the version date is no longer found since now the versions linked to an employee are also archived once the employee is archived. So, active_test has to be used to make sure we can find the date_start of the employee to compute to worked hours to pay in the payslip. This commit uses active_test once the employee is archived to be able to fetch the versions related since they are also archived thanks to the changes made in community. Community PR: odoo/odoo#243248 task-5349397
This update resolves an issue preventing the creation of overtime attendance records across multiple days for employees. The fix addresses a technical error that caused a system failure when attempting to schedule overtime shifts spanning consecutive days. This ensures accurate overtime tracking and avoids disruptions to employee scheduling.
Original PR description
An expected singleton error is raised when we try to create an attendance on multiple days Steps to reproduce: 1. Install Attendances and Work Entries 2. Go to Employees and open Anita Oliver 3. Go to Settings tab and set the Overtime Ruleset to Default Ruleset 4. Go to Attendances and create a new attendance for employee Anita Oliver from Friday 12:00 AM to Saturday 2:00 AM 5. An error is raised Problem: ... Solution: ... opw-5946944
This update corrects an issue where Chilean VAT invoices (l10n_cl_edi) could generate negative folio numbers when no Chilean Fiscal Authority File (CAF) was configured. The fix ensures that folios are correctly assigned, preventing sequence corruption and costly database retries. This improves invoice accuracy and stability.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update resolves an issue where GS1 barcode filtering would fail due to an error when the barcode contained date information. The fix allows the system to correctly filter products based on GS1 barcodes, even if they include date components, ensuring accurate internal transfer tracking.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update corrects a visual issue where the live chat button in the edit mode on desktop wasn't correctly sized. The fix ensures the button takes up the appropriate space, and also resolves a related issue where a fallback button was incorrectly displayed when no live chat link was available. This improves the user experience for editing live chat configurations.
Original PR description
This is a small fixup of 55ade43b18e2896b8dbf0f3364b0f4956faee14b Scenario: in edit mode and desktop, add ai livechat snippet block with no fallback or livechat button. Result: only when editing, the livechat button doesn't take 100% of container width. Cause: the change of 55ade43b18e2896b8dbf0f3364b0f4956faee14b tried to be minimal and missed this use case in the merged 19.0 solution. Fix: in template ai_website_livechat.s_ai_livechat_edit, copy exactly the structure of ai_website_livechat.AILivechatComponentedition. Note: also fixes that the fallback button is shown even when there is no link since df05441e469157890253b5550b5f8735723b28fb. opw-5458575
10 changes
Resolved issues and error corrections
This update corrects a bug where changes to view ordering within the Odoo Studio interface weren't consistently applied. The fix involved updating the default order setting on the relevant database model, ensuring that view order changes made through the Studio are now correctly reflected. This improves user experience and simplifies view customization.
Original PR description
Bug === When changing the order of the views using studio, it wasn't applied. The reason is that we add a default order at the wrong place in JS, it should be done with the attribute made for that, `defaultOrderBy` on the relational model. Task-6047024
This update corrects a bug in the Sendcloud delivery service that was caused by incorrect Python slicing. The fix ensures that the intended first element is retrieved, preventing an error. The issue was not caught during testing due to missing CI test runs.
Original PR description
Slicing in Python returns a sub-list, even for a single element. Doing `res[:1]` does not return the first element so doing `.get` causes an error. This was not caught because the tests do not run in CI due to the tags on the class.
This update fixes a visual problem where the map view in the "My Dashboard" sometimes collapsed or didn't display correctly. The changes removed conflicting height settings and added a minimum height to the map, ensuring it always occupies the appropriate space and displays reliably.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that 'All' folder uploads now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290
This update resolves an issue preventing invoices with discounts and decimal values from being correctly formatted for ARCA (Argentine Electronic Invoice). The fix uses a truncated unit price for discount calculations to ensure accurate decimal precision, avoiding errors related to WSFEX 1812.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value.
This update corrects a bug that caused the Odoo purchase order data fetching process to fail when the last fetch date was reset to 'False' on a company. The fix ensures that cron jobs run smoothly and reliably, preventing data synchronization issues. This improves the accuracy of purchase order information.
Original PR description
In case the purchase last fetch data is resetted to `False` on the company, the next cron run will crash with: `type object 'datetime.datetime' has no attribute 'datetime'` This commit fix the wrong default date fallback. opw-5220129 Forward-Port-Of: odoo/enterprise#111124
This update fixes an issue in our tax reporting module where calculations for previous tax periods were inaccurate, particularly with trimester-based tax periods. The change ensures correct period boundaries are used, preventing incorrect report values and improving the reliability of tax reporting data. This impacts financial reporting accuracy.
Original PR description
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly…
To reproduce the issue: - Setup tax periodicity to "trimester" - Create a report evaluating something with previous_tax_period date_scope (real cases tend to do that for carryover ; see monthly Italian tax report for an example) - Create the appropriate data so that in the current trimester, the report line evaluates to 42, and to 1 in the previous trimester - Open the report for the second month of the trimester => The line has value 42, while it should have 1. This happens because the date bounds for previous_tax_period were computed too naively, considering the date_from was always the first day of the tax period. The first day of the second month of the trimester, it's not the case, and we return the period boundaries of the day before that day. That day is the last day of the first month of the trimester, but belongs to the same trimester, so it's the same tax period. Therefore, we display the value of the current tax period, which is wrong. Forward-Port-Of: odoo/enterprise#110504
This update corrects a visual issue where the company header in accounting reports appeared grayed out in dark mode. The change ensures the header uses a consistent muted color scheme across all Odoo environments, improving the user experience and visual appeal.
Original PR description
Before this pr: - The company header in the accounting reports is grayed out in the light mode only, not in the dark mode. Reason: - Until now, we have been using the hard-coded 'lightgrey' color for the company header. After this pr: - In this pr, we are changing the color of the company header from hard-coded 'lightgrey' color to the standard variable color '--AccountReport-muted-data-color' used for muted data in account reports. Task-5960592 Forward-Port-Of: odoo/enterprise#110108
This update fixes a discrepancy in the French Profit & Loss report. The report was incorrectly double-counting account 649, leading to inaccurate financial totals. The fix ensures that account 649 is correctly categorized within the 'Wages and Salaries' section, aligning with French accounting standards and improving report accuracy.
Original PR description
**Steps to reproduce:** 1. Install module `l10n_fr_reports`. 2. Switch the company to a French localization. 3. Go to Accounting > Reporting > Profit and Loss. 4. Open the section **Operating Expenses**. 5. Check amounts in *Social security charges* and *Wages and salaries* from info. **Issue:** Account 649 was included in two sections of the Profit and Loss report: *Salaires et traitements* (Wages and salaries) *Charges sociales* (Social security charges) Because of this duplication, the total amount in the P&L report does not match the expected accounting values. **Solution:** Remove accounts *649%* from the *Social security charges* section so they are only counted in *Wages and salaries*, which aligns with the expected French accounting structure. Confirmed with PO opw-5976865
This update ensures that changes to a subscription's salesperson are automatically reflected for all associated contacts. Previously, updates only applied to the main company partner, leading to inconsistencies. This change improves data accuracy and reduces the need for manual updates.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271
3 changes
Resolved issues and error corrections
This update fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a missing vehicle ID in the payslip data, which was resolved by recalculating vehicle information using payslip line IDs. This ensures the 281.10 report can now be reliably generated.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206This update resolves an issue where the W4 filing date was incorrectly associated with the employee's W4 form completion. The change ensures the system accurately records when the W4 is submitted to the employer, improving payroll accuracy and compliance. This fix addresses a previous reporting discrepancy.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780
This update fixes a reporting issue where the KMD INF report incorrectly included partners with turnover below 1,000 EUR. Now, the report accurately filters partners based on total invoice and credit note amounts, ensuring more precise financial reporting. The logic considers both invoices and credit notes, as well as Part B transactions.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606