Thursday, December 11, 2025
19 changes · 18.0
Enhancements to existing features
This update enhances the formatting of invoices generated for the Co-dian region in Odoo. Specifically, it standardizes the way floating-point numbers are formatted within the account_edi_common module, ensuring accurate and compliant invoice generation. This change improves the reliability of financial reports and tax filings for Co-dian customers.
PayPal requested the addition of identifiers to Odoo transactions to improve tracking and reconciliation of payments. This change allows PayPal to better understand which transactions originated from Odoo, streamlining their reporting and support processes. It's a minor update focused on enhancing PayPal's visibility into Odoo-related payments.
Original PR description
PayPal requested that we add an identifier so that they know which transactions are coming from Odoo for better trackability. task-5358321 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update corrects a potential issue in the Chilean VAT (l10n_cl_edi) module where an incorrect sequence number could be generated if a specific journal setting wasn't properly configured. This prevented errors when creating VAT documents and ensured accurate VAT processing. The change improves the reliability of the module.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813
This update resolves an issue preventing users from loading demo data in the Appraisal module when creating a new company. The fix uses elevated permissions during demo data loading to bypass company-specific access restrictions, allowing users to successfully load the sample data.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal_skills` without demo data. 2.…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal_skills` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue, you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/19.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
````
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit resolves the issue by using sudo during demo data loading to ensure the required access rights are granted.
sentry-7032880299This update ensures that manually set currency rates for foreign currency invoices are preserved when the invoice is posted. Previously, the system automatically recalculated rates, leading to potential discrepancies. This fix maintains the user's intended rate, improving accuracy and reducing errors in financial reporting.
Original PR description
When creating a customer invoice in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. This fix ensures that any manually entered rate is preserved during posting. The problem was that when posting the invoice_date field changes and the function compute_invoice_rate were called. Solution check if it is manually inserted and do not compute the invoice_rate again task-5391774 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where background colors were lost when copying tables from the Knowledge editor to other Odoo applications. The change ensures that the correct formatting is preserved during copy and paste operations, improving the user experience when working with tables.
Original PR description
To make it possible to properly copy DOM elements across editors, the `application/vnd.odoo.odoo-editor` mimetype was introduced in the `ClipboardPlugin`. However, this was not used inside the `HtmlViewer`. Because of this, some content formatting could be lost when copying elements from an `HtmlViewer` to an editor. This commit solves this by also invoking the code that fills the clipboard in `ClipboardPlugin` when content is copied in an `HtmlViewer`. Steps to reproduce: - Insert a table in Knowledge - Set a background color on a few cells - Use the "lock" feature of Knowledge (inside a dropdown the menu on the right) - Select the entire table - Copy/paste it in a project task => The background colors in the cells were lost task-4017841
This update corrects a printing issue where Sale Order PDFs using the DIN5008 document layout displayed customer addresses twice. The fix prevents this duplication by ensuring addresses are only added once, specifically when the 'Customer Addresses' setting is disabled. This ensures consistent and accurate reporting for our German clients.
Original PR description
## Issue: When DIN5008 is selected as the document layout, printing a Sale Order may show the customer address twice ## Cause: The address is first added by `external_layout_din5008`, then again by `report_saleorder_document` This duplication only makes sense when the partner address differs from the invoice or delivery address If the Customer Addresses setting is disabled, displaying it multiple times is unnecessary ## Steps to reproduce: - Install a company using DIN 5008 (e.g., l10n_de) - Select the DE company and go to Settings - Disable `Customer addresses` and ensure the document layout is set to DIN 5008 - Create a Quotation with any customer and product - Print the PDF → the address appears twice before the fix opw-5176593
This update resolves an issue where branch users couldn't see matching entries in the reconciliation screen. The fix ensures that the system correctly retrieves accounts based on user access permissions, allowing accurate reconciliation for branch operations. This improves the usability of the accounting module for branch-specific transactions.
Original PR description
**Steps to reproduce:** - Install Accounting - Create a branch company - Switch to the branch - Create a Bank journal for the branch - Create a Sales journal for the branch (You can duplicate the journals from the parent company) - Make sure that the accounts configured on the journals are linked the branch - Grant only access to the branch to a user - Connect with that user - Create an invoice - In the bank journal, create a statement line matching the amount of the invoice - Select the statement line **Issue:** In the "Matching Existing Entries" tab, there is no entry. **Cause:** When retrieving the accounts required for the domain to fetch these entries, no account can be retrieved because the user doesn't have access to the parent company. opw-5181909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that a 'partner ID' is always required when creating SEPA payments in Odoo. Previously, missing this information could cause errors during batch payment creation, leading to processing disruptions. This change improves payment stability and reliability for SEPA transactions.
Original PR description
When doing a payment with SEPA as the payment method, and then create a batch payment out of it. It could happen that the partner_id of the payment was not set. That would cause a traceback because in the _get_CdtTrfTxInf we do a browse on the partner to use it later on. But since the partner is False, we have an empty record set. task-5213880
This update fixes an issue where the Partena export file incorrectly used the active company's code when generating exports for inactive companies. The change ensures the correct Partena code is included in the CSV file, resolving a potential data discrepancy for Partena reporting. Tests have been added to verify this fix.
Original PR description
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install…
### Issue: In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file. ### Steps to reproduce: - Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company - Make sure the company has a "Partena Affiliation Number" - Create an employee for this company, with a "Partena code" - Create a contract for this employee, set it a running - Create a new Belgian company with a different "Partena Affiliation Number" - Activate both Belgian companies, but set the second one as active - Payroll > Reporting > Export work entries to Partena - Create a new one, populate it with the employee just created - Click "Generate Export File" ### Cause: When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values. ### Solution: Use `self.company_id` instead of `self.env.company_id`. Also adds the test class with basic tests. opw-5345786
This update ensures that coupon emails sent to customers use the localized date format (e.g., yyyy-MM-dd) based on their language settings. Previously, emails displayed a technical date format, causing confusion. This change improves the customer experience by presenting dates in a familiar and understandable way.
Original PR description
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount…
Steps to reproduce: 1. Install `loyalty` and `sale_management` 2. Activate another language with another date format, eg. English (AU) 3. Set that language on a contact 4. Sales > Product > Discount & loyalty 5. Create a record with program type coupons 6. Generate a coupon for that AU contact with an expiration date Issue: The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format. Cause: We are not using a formatted date according to the customer before: Customer with English AU language <img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" /> <img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" /> After: <img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" /> <img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" /> opw-5247621
This update corrects a previous error that prevented users from saving XML files within the Odoo Studio. Specifically, the system would throw an error when an XML encoding declaration was included. The fix ensures a clearer error message is displayed, guiding users to correctly format their XML files.
Original PR description
Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor. **Steps to produce:** - Install the `web_studio` module and enable `developer mode` - Open `Apps` > `studio` > `view` > `</> xml` - Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save` **Error:** `ValueError: Unicode strings with encoding declaration are not supported. Please use bytes input or XML fragments without declaration.` **Root cause:** At [1], an error is raised when the XML declaration contains an `encoding` attribute, as encoding declarations are invalid in Unicode strings. **Fix:** This commit ensures that a `UserError` is raised, improving the error message clarity. A similar fix was applied in https://github.com/odoo/odoo/pull/205324. [1]: https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316 sentry-6981234548
This update resolves an issue where removing a combo name and then clicking 'Edit Configuration' on an order line would trigger an error. The fix ensures that the 'Edit Configuration' option is only displayed when a product template is associated with the combo, improving usability and preventing unexpected errors.
Original PR description
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management`…
Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered. Steps to replicate: - Install `sale_management` with demo and create a new SO. - Add a combo product and remove the combo name and click Edit Configuration (pencil icon). Error: `TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'` Cause: - When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered. Solution: - Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present. Similar PR for reference: https://github.com/odoo/odoo/pull/217464 [1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that caused the Gantt chart to crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing errors related to comparing dates with boolean values. This improves the stability and reliability of event scheduling.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update resolves an issue where Odoo's logging system incorrectly handled complex log messages containing mappings. The fix moves the message formatting logic to the logger, ensuring accurate log output and preventing data loss. This improves the reliability of Odoo's logging and helps identify potential problems more effectively.
Original PR description
When `lower_logging` encounters a `LogRecord.args: Mapping`, it fucks up and strips out all the values keeping only the mapping keys (as a tuple), which then breaks when trying to format it in `LogRecord.msg`. Fix the issue by moving the entire message munging into, appropriately, the formatter: `getMessage` will do the `str.__mod__` call at which point we don't need to deal with the args at all, then `formatMessage` generates the full message line (not including the stack traces from `exc_info` and `stack_info`, those are added in the second half of `Formatter.format`). https://runbot.odoo.com/odoo/error/234669 Forward-Port-Of: odoo/odoo#239454 Forward-Port-Of: odoo/odoo#239410
This update removes a confusing measure from the Task Analysis report, preventing double-counting of time across tasks and subtasks. The change simplifies reporting by eliminating the 'Hours by Tasks (including subtask)' measure, ensuring more accurate project time tracking. This update is specific to version 18.0.
Original PR description
Steps to Reproduce --- Go to Project -> Reporting -> Task Analysis and switch to pivot view or graph view. Issue --- The "Hours by Tasks (including subtask)" measure duplicates due to the complicated hours counted on main task Current Behaviour --- Total time for a project is summed twice due to the inclusion of subtask hours in both parent and child tasks. Expected Behaviour --- Remove the measure Hours by Tasks ( including subtask) from both pivot and graph views. Fix --- Removed the "Hours by Tasks (including subtask)" measure from the Task Analysis report to avoid confusion. This change applies only to version 18.0. Related:https://github.com/odoo/odoo/pull/184934 task-5144487
This update fixes a potential user confusion during POS session closure. When a cashier isn't properly selected, a notification is now displayed, guiding the user to complete the process. This enhances the overall user experience and prevents errors.
Original PR description
After this commit, when attempting to close a POS session, if the logged-in employee is not selected, a notification will inform the user. This prevents confusion. opw-5244818 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where unscheduled shifts weren't immediately reflected in the Gantt view, requiring a page refresh. The change ensures shifts are updated instantly after being unscheduled, providing a smoother and more reliable planning experience. This eliminates a frustrating user experience and improves data accuracy.
Original PR description
**Steps to reproduce:** Go to planning gantt view. Click on shift. Click on unschedule button on popover. **Issue:** When clicking on Unschedule button on a shift popover, sometimes the shift still appears and again clicking on that it cause missing error occured until the page is refreshed. **Cause:** The record wasn’t updating in the view after a shift was unscheduled, so the unscheduled shift was still showing. **Fix:** Modified the method to reload the model and notify the view immediately after calling action_unschedule, ensuring shifts reflect the latest server state without requiring a manual refresh. task-5075381
This update resolves two issues related to invoice attachments in Odoo. Previously, incorrect invoice formats prevented attachment buttons from appearing, leading to errors. Additionally, warnings about unsupported attachments persisted even when the 'peppol' sending method was disabled, now these warnings are correctly removed.
Original PR description
[FIX] account{_edi_ubl_cii, _peppol}: Attachment fix
2 scenarios fixed in this commit :
1:
When a user invoice_edi_format is not 'ubl_bis3' the attachment button is not displayed and the key doesn't exists in the invoice_data. This causes traceback when trying to access the key.
2:
When a user send and print an invoice, with 'email' and 'peppol' as sending_methods, warnings will be displayed next to attachments not supported by peppol.
But if the user uncheck 'peppol', warnings will stay while no sending method requires them anymore.
See odoo/odoo#234339