Daily updates from Odoo
Navigate
Branch
Friday, March 20, 2026
248 changes
10 changes
New functionality added to Odoo
This update reflects recent changes in Belgian tax regulations regarding deductible expenses. The update modifies key accounting data (accounts 616580, 616541, 623610) to ensure compliance with the latest government rules. This ensures accurate financial reporting for businesses operating in Belgium.
Original PR description
Belgian Government changed some rules regarding the fiscal deductibility of some expenses, so we need to update that data accordingly for accounts 616580, 616541, 623610 Task-5973880 Forward-Port-Of: odoo/enterprise#110075
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
21 changes
Enhancements to existing features
This update enhances the security and reliability of exporting large spreadsheet datasets from Odoo. It adds logging for common export scenarios (downloading, copying, printing) and restricts access to frozen or XLSX spreadsheets to authorized users, preventing unauthorized data access. This improves data integrity and security.
Original PR description
Forward-Port-Of: odoo/enterprise#108959 Forward-Port-Of: odoo/enterprise#85888
This update adapts the French financial reporting process to changes in how data is exported from Odoo. Instead of downloading entire files, data is now streamed to the user, improving efficiency and reducing download times. This ensures accurate and timely reporting for French customers.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#107017 Forward-Port-Of: odoo/enterprise#102783
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#1112024 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
6 changes
New functionality added to Odoo
This update incorporates a new rule (SE-R-005) from the PEPPOL BIS3 standard for electronic invoices. This ensures Odoo complies with European regulations for invoice billing, specifically related to accounting and financial transactions. This change is important for businesses using Odoo to generate invoices that need to meet PEPPOL standards.
Original PR description
Rule information: https://docs.peppol.eu/poacc/billing/3.0/2025-Q4/rules/ubl-peppol/SE-R-005/ OPW-5881918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250657
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
6 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
36 changes
New functionality added to Odoo
This update reflects changes in Belgian government regulations regarding the deductibility of certain business expenses. The update incorporates new fiscal rates and account codes (616580, 616541, 623610) to ensure accurate accounting and tax reporting in Belgium. This ensures compliance with current tax laws.
Original PR description
Belgian Government changed some rules regarding the fiscal deductibility of some expenses, so we need to update that data accordingly for accounts 616580, 616541, 623610 Task-5973880 Forward-Port-Of: odoo/enterprise#110075
This update allows users to create Documents records directly from employee files uploaded through standard form fields. Previously, this feature was blocked for attachments with a specific field setting. This change improves the process of managing employee-related documents within Odoo Enterprise.
Original PR description
TEMP
This update incorporates the 2033-E document, a key component of the French 'Liasse fiscale' reporting requirement. This addition ensures our Odoo Enterprise system is fully compliant with French tax regulations, facilitating accurate financial reporting for our French clients.
Original PR description
This commit will add the 2033-E document of the "Liasse fiscal" task-5417361
Enhancements to existing features
This update loosens restrictions on creating leave for employees with Swiss payroll, allowing leave creation even when a payslip is validated. Specifically, it now permits leave creation under certain conditions related to continued pay percentages and disability benefits, improving flexibility for HR processes. This change ensures accurate leave tracking within the Odoo Enterprise system.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
This update streamlines the job promotion process by removing redundant buttons and adjusting user access rights. Specifically, the 'Post on Job Board' button has been removed as it's now accessible through another option, and the 'Promote' button's access has been restricted to 'officer' users, enhancing security and workflow efficiency.
Original PR description
This commit is part of a 9-part task aiming to improve the user experience of multiple apps related to hr_recruitment. This commit: - removes the radio button in the job promotion wizard - removes the "Post on Job Board" button, since that action already exists in the cog menu (albeit under a different name: "Publish on Job Board") - changes the access rights of the 'Promote' button on a Job Form from 'admin' users to 'officer' users task-5184168
This update introduces a new system for automatically analyzing Seculine return files after salary declarations. It centralizes all feedback responses, allowing for quicker identification and resolution of any errors reported by the Seculine platform. This improves payroll accuracy and reduces manual effort.
Original PR description
- With this commit, we introduce a new model to handle the Seculine return files that are sent back by the Seculine platform after salary declaration to analyze and see the errors if any. - Centralizes all necessary responses required by Seculine for salary declaration feedback. task-4737849
This update enhances the visual appearance of spreadsheet controls by adopting a custom component, improving the overall user experience. This change focuses on the spreadsheet edition within Odoo, aligning its design with other Odoo modules. It's an internal improvement to the user interface.
Original PR description
We implemented a custom `Select` component in o-spreadsheet to improve the look and feels over native `<select>` elements, but didn't change the `<select>` present only in Odoo. Task: [6043744](https://www.odoo.com/web#id=6043744&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
This update simplifies the user experience by replacing all 'Cancel' buttons with 'Discard' buttons across several Odoo modules. This change improves clarity and consistency for users, allowing them to easily revert actions without confusion. The change is a minor improvement to the user interface.
Original PR description
Use Discard rather than Cancel Task: [5353199](https://www.odoo.com/odoo/2328/tasks/5353199)
This update enhances the user experience by adding visual warnings when accounts linked within Odoo are marked as inactive. This helps users quickly identify and manage inactive accounts, preventing potential errors and streamlining financial processes. The change impacts several accounting modules.
Original PR description
This commit will add a related field for each many2One linked to an account so that we can have a decoration to warn the user that this account is inactive. task-542461
This update centralizes how external requests are mocked across various Odoo modules. This change improves control over access to external resources and simplifies default settings, leading to more reliable and consistent testing. It's a foundational step towards better security and maintainability.
Original PR description
Centralize all requests-related mocking in one place This is a first step in our effort to centralise requests/responses/session objects in order to have better control on what should and should not be accessible to internal and to server action developers, as well as improve defaults. Creating a facade for most requests/responses & session objects breaks a lot of tests, as each module mocks responses in their own way, and thus makes building minimal facades difficult. task-4930532 Related: https://github.com/odoo/odoo/pull/249057
This update redesigns the survey results reporting page by adapting key Odoo addons like documents_spreadsheet and hr_appraisal to align with the overall survey redesign. This ensures a more consistent and user-friendly experience for analyzing survey data.
Original PR description
*: documents_spreadsheet, hr_appraisal Adapt different addons to the results (statistics) page of surveys as a part of the main redesign. Community PR: https://github.com/odoo/odoo/pull/247409 task-3884703
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
Features or functions removed from Odoo
This update streamlines the return process by removing a complex wizard and now automatically opens a draft picking form for returns. Users must now confirm the return picking to enable exchanges, improving efficiency and clarity. This change impacts the stock and helpdesk modules.
Original PR description
This commit removes the return wizard `stock.return.picking` and now returning a picking opens a picking form in draft state so the user can assign the quantities to return. Also, in order to make an exchange you need to confirm or validate the return picking first to be able to make an exchange. There is still a wizard used in helpdesk modules to accommodate choosing a picking first on the ticket to make the return. Related community PR: https://github.com/odoo/odoo/pull/241646 Related upgrade PR: https://github.com/odoo/upgrade/pull/9168 Task-5347991
This update removes user activities from the calendar view within the Point of Sale (POS) system. Previously, user activities were displayed, which was causing performance issues and unnecessary complexity. This change simplifies the POS experience and improves system efficiency.
Original PR description
Following odoo/odoo#244236 user activities can now be displayed in the user calendar. Prevent loading and displaying the user activities in point of sale. Task-5428944
Code cleanup and technical improvements
This update clarifies the names of key fields related to reinvoicing policies, enhancing clarity and consistency. Additionally, the model and view files for the timesheet functionality have been renamed to align with standard Odoo naming conventions, improving code organization and developer readability. This change supports ongoing improvements to reporting.
Original PR description
This PR renames several fields to better reflect their purpose and follow naming guidelines. Fields: * `expense_policy` → `reinvoice_policy` * `visible_expense_policy` → `visible_reinvoice_policy` Files: * `models/hr_timesheet.py` → `models/account_analytic_line.py` * `views/hr_timesheet_views.xml` → `views/account_analytic_line_views.xml` `expense_policy` and `visible_expense_policy` are renamed because these fields are no longer specific to expenses and now represent the generic reinvoicing behavior. `hr_timesheet` model and view files are renamed to `account_analytic_line` since We generally avoid functional naming for model or view files, and having the code for the `account.analytic.line` model inside a file named `hr_timesheet` does not add much clarity to devs. follow up of task-5490517 See Also: - https://github.com/odoo/odoo/pull/252144 - https://github.com/odoo/upgrade/pull/9609
This update streamlines access control for spreadsheet cells within Odoo Enterprise. The changes consolidate existing permission rules, eliminating redundant checks and improving the overall efficiency of the system. This ensures consistent and reliable access to spreadsheet data.
Original PR description
Use access rules defined and don't create additional permission checks.
This pull request integrates the 'l10n_be_intervat' module into the 'l1n_be_reports' module. This update enhances the reporting capabilities within Odoo Enterprise for Belgian Intervat tax returns, streamlining the process for businesses to accurately track and report VAT obligations.
Original PR description
This PR merges 'l10n_be_intervat' module into 'l10n_be_reports'. upgrade PR: https://github.com/odoo/upgrade/pull/9073 task-5090001
This update prepares Odoo for OWL3 by automatically adding `.this` to template variables that reference component data. This change is necessary because OWL3 requires a specific syntax for accessing component variables within templates, ensuring compatibility with the new OWL3 environment. The changes impact several Odoo modules, primarily within the web_studio environment.
Original PR description
In preparation for OWL3, where template variables will need to use `.this` to target component variables, we add `.this` to template variables that are targetting the component. Community PR: https://github.com/odoo/odoo/pull/254637 Script PR: odoo/odoo#247965 task: OWL3 prep - add this. to template variables
6 changes
Enhancements to existing features
This update prioritizes synchronization of a user's databases, ensuring they see their key performance indicators (KPIs) first. By changing the synchronization order, it reduces the risk of databases being queued unnecessarily, leading to a smoother and more responsive experience for users.
Original PR description
The aim of this commit is to make sure the dbs from the current user are synchronized first allowing the user to see his db kpi first. Before this commit: The dbs were synchronized according to the default order of `project.project`. After this commit: The user dbs get synchronized first reducing the risk for those to be queued in the CRON. task-id: 5951983
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
9 changes
New functionality added to Odoo
This pull request updates the .weblate.json files to include translations for additional modules within the Odoo Enterprise system. This ensures that all user-facing content is accurately localized for different languages, improving the user experience for international customers. It's a routine maintenance task to maintain the quality of our translations.
Original PR description
Related: https://github.com/odoo/odoo/pull/254667 Forward-Port-Of: odoo/enterprise#111141
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
2 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