Daily updates from Odoo
Thursday, March 19, 2026
248 changes
24 changes
Enhancements to existing features
This update allows for leave creation even when an employee has a validated payslip, providing greater flexibility for HR. The change relaxes previous restrictions based on payroll impact and disability percentages, ensuring employees can schedule leave without impacting payroll calculations. This improves the user experience for Swiss clients.
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
Resolved issues and error corrections
This update fixes a problem where users only installing the Mexico payroll module (l10n_mx_hr_payroll) would encounter errors due to a missing field. The fix ensures salary rules are correctly applied by utilizing the 'zsmg' value and resolving potential tracebacks when the related EDI module is not present. This improves the stability and functionality of payroll calculations for Mexican businesses.
Original PR description
The `l10n_mx_min_wage_zone` field is used in `l10n_mx_hr_payroll`, but it was originally defined in `l10n_mx_hr_payroll_account_edi`. This causes errors when a user only installs the `l10n_mx_hr_payroll` module, as the field is missing. Fix salary rules in `l10n_mx_hr_payroll` to use the `zsmg` value and avoid tracebacks when the EDI module is missing. In `l10n_mx_hr_payroll_account_edi`, override these rules to use the `l10n_mx_min_wage_zone` field instead. Related commit: https://github.com/odoo/enterprise/commit/11bb6db4884083b3f48582b749c01ae75a09cf66 target: saas-19.2 task-6047772
This update resolves a bug where subscriptions were incorrectly reopened after a credit note payment. The fix prevents the system from reopening subscriptions when a credit note payment (specifically 'out_refund' moves) is processed, ensuring subscriptions remain in the correct churned state. This improves subscription management accuracy.
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 corrects a bug that caused incorrect currency conversions during batch payment reconciliation in foreign currency journals. Specifically, the system was using the wrong currency for balance calculations, leading to inaccurate bank statement line amounts. This ensures accurate financial reporting and reconciliation processes.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#110381 Forward-Port-Of: odoo/enterprise#108745
This update corrects a problem where text fields in Odoo Sign PDF forms were incorrectly displayed as checkmarks instead of the entered text. The issue stemmed from a misinterpretation of Appearance State tags in PDF fields, and this fix ensures text fields accurately reflect the user's input when flattening PDFs for signature.
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#110292
This update clarifies error messages when payments are declined for vendors outside of Belgium. Previously, the message "Country not allowed" was confusing for users. The change now incorporates payment data to provide a more accurate and helpful message, ensuring a better user experience when dealing with international vendors.
Original PR description
A company in belgium creates a card, it's "allowed countries" is set to Belgium by default. If said card is used to pay online on a website ending with .be, it is understandable that the user believes the vendor to be located in Belgium If it is not the case (the vendor is actually in Luxembourg), the payment is refused but the message on the refused expense is unclear "Country not allowed" The change adds the data received to make the decision in the error message task: 5478443 Forward-Port-Of: odoo/enterprise#103974
This update resolves an issue where GS1 barcode filtering would fail due to an incorrect date interpretation. The system now gracefully handles these errors, ensuring that products can be correctly filtered by their barcodes, improving internal transfer accuracy.
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 fix addresses an issue where multiple email addresses associated with a contact were being overwritten when creating a Helpdesk ticket. The update ensures that all email addresses linked to 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 corrects a recent change that disabled a feature (showSeconds) in the MRP modules. Enabling this feature ensures that MRP modules now accurately display the time remaining on work orders and production schedules. This improves visibility and scheduling accuracy for operations.
Original PR description
Previously, showSeconds was True by default. It has now been set to False by default so we need to enable it for MRP modules.
This update simplifies how emoji data is loaded and managed within Odoo, leading to faster test runs and improved performance. The change reorganizes code to allow for better caching and reuse of emoji assets, addressing a previous performance bottleneck. This ultimately contributes to more stable and efficient nightly builds.
Original PR description
Feature that is aimed to ease and centralize the loading and management of emoji data. Follow-up of https://github.com/odoo/odoo/pull/253344 in the same effort to reduce overall memory consumption and increase performance in tests to restore (some) nightly builds. - Community: https://github.com/odoo/odoo/pull/253078
This update fixes a visual issue in the Partner Ledger report where overdue dates weren't highlighted in red and negative amounts weren't displayed in blue. The change ensures that key financial information is clearly visible, improving the accuracy and readability of financial reports. This enhances the user experience for managing accounts.
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.
This update ensures that follow-up emails for invoices now send the actual invoice PDF attachment, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDF documents, ensuring accurate and complete invoice information is 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#110894 Forward-Port-Of: odoo/enterprise#98820
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 is shown to 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 corrects an issue where incorrect folio numbering occurred when a Customer Accounting File (CAF) wasn't set up. The fix ensures folios are generated correctly, preventing errors and maintaining accurate accounting records. This resolves a potential problem with sequence management and avoids unnecessary system retries.
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 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 streamlined, reducing data storage and improving performance for businesses using multiple companies. This change ensures a more efficient and responsive system.
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 transactions resulted in errors. The fix ensures the necessary currency information is included in the report template, preventing rendering problems and ensuring accurate reporting for Luxembourg VAT compliance.
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
Previously, when users uploaded multiple attachments to a WhatsApp Discuss channel, only the first attachment was delivered. This update corrects this issue by implementing a new validation process that prevents sending more than one attachment per message, ensuring all files are successfully transmitted. This improves the reliability of WhatsApp communication within Odoo.
Original PR description
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a…
Multiple attachments uploaded simultaneously to a WhatsApp Discuss channel result in only the first being delivered to the recipient. ### Steps to reproduce 1. Drag and drop multiple files into a WhatsApp Discuss channel. 2. Send the message. -> Odoo shows all files, but only the first reaches the destination. ### Cause WhatsApp's API permits only one media object per message. Odoo's "Composer" enforces this by blocking uploads if an attachment is already present. However, it only evaluates the *current* state; dropping multiple files into an empty composer passes the check because the count is zero. On the server, the WhatsApp backend (constrained by the API) is hardcoded to send only the first attachment, silently discarding the rest. ### Fix Updated frontend validation to inspect the incoming file list during drop and paste actions. The process is now blocked if the total of existing plus incoming files exceeds one, ensuring the user is notified and preventing silent data loss. opw-5889035 Forward-Port-Of: odoo/enterprise#111001 Forward-Port-Of: odoo/enterprise#107424
This update corrects a technical issue that prevented users from opening expenses linked to multiple payments. The fix ensures the system handles expenses correctly, regardless of how many payments are associated with them. This resolves a potential error that could occur during upgrades.
Original PR description
**Description:** In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple expenses. When opening expenses from the payment action,…
**Description:**
In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.
This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.
**To fix the issue**
the code now handles multiple expenses instead of assuming a singleton.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
'name': self.expense_ids.name,
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```
opw-5494047
upg-3974547
[^1]: https://github.com/odoo/odoo/pull/189701
Forward-Port-Of: odoo/odoo#254167Portal users were experiencing errors when submitting website forms that created tasks. This update resolves a restriction in how the system accesses task details, preventing a 'permission denied' error. The fix uses a special system command to allow access to the necessary data, ensuring smooth task creation for all users.
Original PR description
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website…
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website form that creates a task 3) Set a project on the form 4) Submit the form as a portal user ### **Error:** `AccessError: You do not have enough rights to access the field project_privacy_visibility on Task (project.task)` ### **Root Cause:** The confirmation template evaluates `task.project_privacy_visibility` in a t-if condition at [1]. since [commit](https://github.com/odoo/odoo/pull/203891/changes/17664b3f118491f954dd6a810521ce5865d51a43), project task restricts portal users to a whitelist of fields defined by [_portal_accessible_fields()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1015-L1019). Field access is then validated in [_has_field_access()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1021-L1031), which denies read access to fields not present in this whitelist. `project_privacy_visibility` is not part of the portal readable fields list. When the template tries to read it, _has_field_access() rejects the operation and raises an AccessError. [1]- https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/website_project/views/project_portal_project_task_template.xml#L13-L16 ### **Fix:** Use `sudo()` when reading `project_privacy_visibility` in the template to avoid the portal field access restriction. **opw-6010622** Forward-Port-Of: odoo/odoo#254326 Forward-Port-Of: odoo/odoo#254099
This update fixes a bug where the VAT (Tax ID) was not correctly displayed in document layouts like invoices and previews. The issue stemmed from a missing piece of code in the document template. Now, VAT information is accurately reflected in generated documents, ensuring compliance and accurate reporting.
Original PR description
Steps to reproduce 1. Install `account`. 2. Go to Settings → Configure Document Layout. 3. Enter a value in the Tax ID field. 4. Generate a document (invoice / preview document). Issue Unlike other fields in the document layout, the `Tax ID` value is not updated and does not appear in the document preview. Cause The VAT (Tax ID) rendering logic was missing from the document layout template XML. Solution Add proper logic to display the Tax ID using the company VAT Before: <img width="1089" height="750" alt="image" src="https://github.com/user-attachments/assets/8d27808f-d605-447c-807a-d5f3450eef36" /> After: <img width="1080" height="722" alt="image" src="https://github.com/user-attachments/assets/0af04d77-a318-4e39-9a4b-0911f2446e60" /> opw-5373374 Forward-Port-Of: odoo/odoo#249225 Forward-Port-Of: odoo/odoo#240234
This update corrects a technical error in how images are displayed within Odoo's user interface. The fix ensures that images are rendered correctly, resolving a visual issue that may have affected some users. This improves the overall user experience and prevents potential display problems.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update fixes a visual issue in the table picker component of the Odoo interface. Previously, non-active cells in dark mode didn't have the correct background color. This change ensures a consistent and visually appealing experience across both light and dark modes, improving the overall user experience.
Original PR description
Currently in dark mode, we don't display the right bg color for (non active) cells in table picker. This PR uses the right variable for the bg color of non active cell that is more suitable for both light and dark mode. task-6009282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252378
This update ensures that phone numbers entered through the takeaway preset in the Odoo POS system are now correctly recorded on the order itself. Previously, this information was lost, making it difficult to contact customers. This fix improves order accuracy and customer service.
Original PR description
Currently, when using the takeaway preset, the phone information filled in is not registered on the order. Steps to reproduce: ------------------- * Change restaurant setting to enable self order * Open mobile menu (make sure session is opened prior) * Select takeout preset * Place an order * Fill in all information, time, name, email & phone * Validate order * Go to the orders in the backend > Observe that the contact info does not register the phone (mobile) Why the fix: ------------ Nothing was done with the phone information so we now register it on the order. opw-6014340 Forward-Port-Of: odoo/odoo#253610
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly when dealing with large numbers of picking IDs. The fix ensures the system handles large datasets efficiently, preventing crashes and improving performance for users with extensive inventory.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#24882618 changes
New functionality added to Odoo
This update enables the generation of UBL (Universal Business Language) receipts from Point of Sale (PoS) orders, supporting compliance with local tax regulations. The changes include adding UBL 2.1 invoice templates and preparing the system for use with l10n_co POS, improving reporting capabilities for businesses operating in Colombia.
Original PR description
task: 4038651 Forward-Port-Of: odoo/odoo#209578
Enhancements to existing features
This update improves the accuracy of Taiwan's tax calculations by refining fiscal positions and tax mappings, particularly for common document types like invoices. The changes better align with local tax regulations and simplify the chart of accounts by removing outdated tax configurations. This ensures more precise financial reporting for Odoo users in Taiwan.
Original PR description
This commit updates the Taiwan localization to provide a more granular and accurate set of fiscal positions and tax mappings, specifically focusing on document types (Triplicate, Duplicate, and Cash Register). Key changes: - Refactored fiscal positions to differentiate between document types for Export Sales and VAT Exempt transactions. - Split purchase-related fiscal positions into P C (Product/Consumable) and F A (Fixed Asset) categories to better handle tax deduction rules. - Updated `original_tax_ids` on sale and purchase taxes to ensure correct tax substitution when switching fiscal positions. - Cleaned up the tax template by removing redundant or less commonly used taxes (GBRT, Withholding, Deemed Sales, and specific Fixed Asset sale taxes) to simplify the default chart of accounts. - Updated localized names and translations for clarity. Task-6007589 --- 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 fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The solution allows users to manually specify the fulfillment channel (FBA or FBM) for each listing, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update resolves a technical issue that prevented users from correctly editing transactions after multiple reconciliation lines were created. The fix skips a calculation step when multiple reconciled lines are present, ensuring accurate reporting and editing functionality. This improves the stability of the accounting module.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update resolves a performance issue in the Followup Report that was causing slow loading times in Odoo 19.1. The fix utilizes a more efficient filtering method, aligning with previous performance practices, to speed up report generation, particularly on large databases.
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.
This update resolves an issue where renewing a subscription while another renewal process was running would incorrectly mark the subscription as churned. The fix ensures that subscriptions are only processed when their status is actively in progress, preventing this race condition and maintaining accurate subscription management.
Original PR description
Steps to reproduce: - Have a subscription ready to expire/auto-close. - Trigger the `_cron_subscription_expiration` cron. - While the cron is processing earlier batches, manually renew the subscription. - The renewed subscription is incorrectly marked as closed/churned. Cause: The cron searches for all expired/unpaid subscriptions at the very beginning and processes them in batches of 30. If a subscription is renewed concurrently (Race condition), its ID is already in the `subscriptions_close` list, causing the cron to close it regardless of its new state. Solution: Inside the batch processing loop, consider only subscriptions that are strictly still in `SUBSCRIPTION_PROGRESS_STATE`. Task: 5929077 Forward-Port-Of: odoo/enterprise#107157
This update corrects a technical issue in the Account Avatax module, ensuring it properly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates correctly within the Odoo Enterprise system.
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 ensures that PIN codes are now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (digital wallets) because they couldn't access their PIN. This change improves the user experience and allows for seamless transactions.
Original PR description
Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462 Forward-Port-Of: odoo/enterprise#107231
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance when customers were located within the EU. The fix ensures that the 'Only intra-EU customers' check accurately identifies invoices that violate EU regulations, improving data accuracy and reducing potential reporting errors.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update resolves a technical issue within Odoo's Studio feature where view editing sometimes caused errors. The fix ensures that Studio correctly handles inherited views, preventing crashes and improving the stability of view creation. This change improves the overall reliability of the Studio tool.
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 a minor issue preventing the correct display of a tour within the industry FSM report module. The fix ensures that the tour functionality operates as intended, improving the user experience for this specific reporting feature. This change does not impact other parts of the system.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
This update resolves an issue where the Public Administration (PA) invoice status wasn't correctly updated after SDI validation, leading to potential rejection of invoices. The fix ensures the system accurately reflects the PA's state, improving invoice processing accuracy for Italian tax compliance. This change was triggered by a bug fix within the l10n_it_edi module.
Original PR description
### Issue: After the SDI validation, the state was never updated to match the PA state, resulting in a mismatch with the actual status ### Cause: When `l10n_it_edi_state` is set to `forwarded`, the cron `cron_l10n_it_edi_download_and_update` doesn't consider that a new state could occur However, invoices sent to Public Administration can still be rejected after being forwarded It is not possible to reproduce the issue with the demo system, as it only sets the state to `forwarded` Ticket [link](https://www.odoo.com/odoo/project.task/5391891) opw-5391891 Forward-Port-Of: odoo/odoo#254406 Forward-Port-Of: odoo/odoo#253525
This update resolves an issue where ZATCA invoicing was incorrectly applied to ‘Settle Due’ orders in Point of Sale. The change adjusts how the system identifies these orders, ensuring that invoicing is skipped for ‘Settle Due’ transactions while maintaining correct invoicing for standard deposit flows. This prevents duplicate invoicing and simplifies ZATCA reporting for POS transactions.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252984 Forward-Port-Of: odoo/odoo#244712
This update fixes an issue where table menus would overlap or not appear when hovering over list items within table cells. The change now correctly displays table menus on list hover and prevents overflow, ensuring a smoother user experience when working with complex tables. This improves the overall usability of the HTML editor.
Original PR description
**Current behavior before PR:** - Table menu handlers could overflow into adjacent table areas when the targeted part of the table was only partially visible within the container. - When a table cell contained a list, hovering over the list element did not display the table UI menus, even though the mouse was inside the cell. **Desired behavior after PR is merged:** - Use a local overlay for the table menu to prevent overflow into adjacent cells. - Table UI menus are now correctly displayed when hovering over list elements inside a table cell. task-5353518 Forward-Port-Of: odoo/odoo#251977 Forward-Port-Of: odoo/odoo#240342
A recent update caused the copy button within the spreadsheet functionality to become disabled. This fix resolves the issue, ensuring users can now reliably copy their spreadsheets. This improvement maintains the smooth operation of a key feature for managing data.
Original PR description
Fix error which disabled the copy button. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253991 Forward-Port-Of: odoo/odoo#252977
This update ensures that phone numbers entered through the takeaway preset in the Odoo POS system are now correctly recorded on the order itself. Previously, this information was lost, making it difficult to contact customers. This fix improves order management and customer service.
Original PR description
Currently, when using the takeaway preset, the phone information filled in is not registered on the order. Steps to reproduce: ------------------- * Change restaurant setting to enable self order * Open mobile menu (make sure session is opened prior) * Select takeout preset * Place an order * Fill in all information, time, name, email & phone * Validate order * Go to the orders in the backend > Observe that the contact info does not register the phone (mobile) Why the fix: ------------ Nothing was done with the phone information so we now register it on the order. opw-6014340 Forward-Port-Of: odoo/odoo#253610
This update corrects a display issue where the batch view in the stock picking module showed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the process for users creating and managing picking batches. This improves user experience and reduces potential confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/odoo#252630 Forward-Port-Of: odoo/odoo#249581
This update fixes an issue where the formatting of PDF quotes generated with the Din5008 localization module was inconsistent when hiding product compositions. Specifically, the section background and column alignment were misaligned. The fix adds a colspan to section names to ensure proper formatting and a more professional-looking PDF quote.
Original PR description
Steps to reproduce ================== - Install website_sale,accountant,l10n_de - Select the DE company - In the accounting settings, enable the "Show Position Column in Reports" - Go to Sales - Create a new Quotation - Select a customer - Add a product - Add a section - Click on the three dots - Click on Hide Composition - Add another section - Click on the cog menu - Click on Print > PDF Quote => The background of the first section ends before the end of the line => The columns are also not aligned Solution ======== Add a colspan of 2 to the section names opw-5427590 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252029
14 changes
Resolved issues and error corrections
This update resolves a problem where the system incorrectly flagged invoices from intra-EU customers, leading to potential compliance errors with EU regulations. The fix ensures the 'Only intra-EU customers' check accurately identifies invoices for EC Sales List reporting, improving data accuracy and reducing the risk of non-compliance.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update corrects a bug that caused incorrect decimal values to be generated in intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate reporting for international trade data.
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 an issue preventing new employee creation when generating BVG-LLP reports with duplicate monthly data. The fix addresses a technical problem within Odoo's record processing that caused a 'singleton' error. This ensures employees can be created correctly when multiple reports with the same month are present.
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#102335This update resolves an issue where GS1 barcode filtering would fail due to an incorrect interpretation of certain barcodes as dates. The fix prevents errors from blocking product filtering, ensuring internal transfers and barcode scans function correctly. 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 resolves an issue where Odoo generated invalid UBL/QR invoices for foreign customers when a Peruvian company was invoicing a customer with a different country's identification type. The change ensures the correct 'schemeID' value ('0') is used, preventing errors with SUNAT and ensuring proper invoice generation in multi-country scenarios.
Original PR description
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an…
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types. In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like: ``` 2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value). ``` Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia): https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4 This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in: - PartyIdentification/ID/@schemeID - AccountingCustomerParty/AdditionalAccountID - the QR payload identification type field This prevents generating invalid UBL/QR content for foreign customers in multi-country setups. Forward-Port-Of: odoo/enterprise#105115
This update resolves a timing issue that was causing delays in the website's onboarding tours, particularly related to translation loading. The fix ensures that translation requests are handled promptly, preventing interruptions and improving the user experience. This was triggered by recent changes in Chrome versions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update corrects a calculation issue related to employee appraisal dates. The fix ensures appraisal dates are accurately determined based on company settings like recruitment duration and appraisal schedules. This improves the reliability of appraisal workflows within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719
This update corrects an issue where incorrect folio numbering occurred when a Chilean Accounting (l10n_cl_edi) configuration wasn't set up. The fix ensures folios are correctly generated, preventing errors and maintaining accurate accounting sequences. This improves the reliability of financial data 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 visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to the map, ensuring it 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 long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users in the Keňa (Kenya) edition of Odoo Enterprise. This enhancement ensures accurate reporting and a better user experience.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update resolves an issue where generating VAT reports (FAIA) for invoices in different currencies caused a rendering error. The fix ensures the necessary currency information is included in the report, 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 corrects a sizing problem with the company logo across various Odoo reports. The previous CSS selector was too broad, affecting multiple reports and causing the logo to appear oversized. This change ensures the logo displays correctly and consistently in all reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432
This update resolves an issue where tests were incorrectly deleting taxes in reports related to the Indian Goods and Services Tax (GST). The change now properly removes taxes from the account move line, ensuring accurate reporting calculations and aligning with current tax regulations. This improves the reliability of the GSTR reports.
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#105174
This update corrects a technical error that caused the Odoo Enterprise system to crash when resetting purchase data fetching settings for a company. The fix ensures that the system correctly retrieves purchase data, preventing future disruptions and maintaining accurate records. This resolves a previous issue impacting data reliability.
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
19 changes
Resolved issues and error corrections
This update corrects a bug that was causing incorrect decimal values to be generated in intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate intrastat reporting, preventing potential discrepancies with tax authorities.
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 an issue preventing Odoo from correctly generating UBL invoices for Hungarian businesses. The problem stemmed from a requirement that VAT numbers always start with a country code, which is not standard practice in Hungary. The fix automatically builds the VAT number from the Hungarian Tax Number, ensuring invoices meet regulatory requirements and can be successfully sent to the NAV.
Original PR description
Problem --------- When building the UBL, invoices with Hungarian partners get hit with the following constains: "The VAT of the [role] should be prefixed by the country code". However, Hungary allows for VAT numbers that do no start with the country code. Every Hungarian business is assigned a Tax Number (Adószám) that follows a fixed 11-digit format: NNNNNNNN-Y-CC. Solution --------- Build the VAT number from the Domestic Tax Number if it is not the case. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253663
This update prevents the forum from freezing if it takes too long to retrieve information. By adding a timeout to the requests, the forum now responds more reliably, improving the user experience and preventing potential downtime. This is a routine maintenance fix.
Original PR description
Add a timeout to the requests done by /forum/get_url_title to avoid blocking indefinitely Forward-Port-Of: odoo/odoo#254607
This update fixes an issue where stock move lines were incorrectly assigning destination packages, particularly for reusable packaging. The change ensures that destination package assignments are only applied to disposable packaging, streamlining the process for both full packs and individual deliveries. This improves the accuracy of stock tracking.
Original PR description
Commit https://github.com/odoo/odoo/commit/0358963e2088a309141f092fbe8f7a98786cc1d8 forces the `result_package_id` on the package level stock move lines (meaning move lines being part of entire package move) to be the source package. This makes sense when moving entire packs but not in case of delivery with disposable packages. We remove the line that set the destination package for any package type and keep the one doing this for disposable package only. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253323
This update resolves an issue where users lacking live chat permissions would encounter an error when trying to open the invite panel. The change ensures that active live chat partners are correctly retrieved for invited users, improving the usability of the live chat feature. This prevents frustration and ensures a smoother experience for all users.
Original PR description
When opening the livechat invite panel, users without livechat access rights encounter an access error. This commit fixes the issue by ensuring active live chat partners can be retrieved for invited users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a user experience issue where generating PDFs for multiple employee declarations didn't process all records when using the 'Select All' feature. Now, selecting all records and generating PDFs will process all drafts, and users can easily regenerate existing PDFs. This ensures a smoother and more reliable process for generating employee declaration 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
This update fixes an issue where reasons provided by Public Administrators when refusing invoices weren't displayed in Odoo. Now, the reason message (EsitoCommittente/Descrizione) is shown on the invoice header, ensuring accurate record-keeping related to invoice refusals. This ensures compliance with Italian tax regulations (FatturaPA).
Original PR description
When a Public Administrator business refuses an invoice, they also give a reason message (EsitoCommittente/Descrizione), which comes through the IAP to Odoo as an XML tag aside the Outcome code (EsitoCommittente/Esito). Before this PR, the message was ignored, now we show it in the invoice's header. ref: https://www.fatturapa.gov.it/export/documenti/messaggi/v1.1/MessaggiTypes_v1.1.xsd <img width="823" height="232" alt="image" src="https://github.com/user-attachments/assets/8f222f6b-1615-4dd2-a5dd-25e0991ea037" /> <img width="942" height="206" alt="image" src="https://github.com/user-attachments/assets/cdf109ff-40d0-4c50-bdc7-51fb4ea15c98" /> Ticket [link](https://www.odoo.com/odoo/project.task/6041276) opw-6041276 Forward-Port-Of: odoo/odoo#254481
This update ensures that when importing tasks from spreadsheets into Field Service, the recurrence settings specified in the spreadsheet are correctly applied, rather than defaulting to standard recurrence values. Previously, importing tasks without a recurrence ID would overwrite these settings. This change improves data accuracy and consistency for task scheduling.
Original PR description
### Steps to reproduce: - Create a xlsx sheet with some fsm_tasks values with recurrence values - Import the sheet to Field Service > Tasks - Navigate to the created tasks - Notice the recurrence values is the default ones not the ones in the imported sheet ### Cause: If we are importing records without recurrence_id value we will set the recurrence fields' values to the default values while we might already have values for those fields ### Fix: Check if we have values for recurrence fields we don't set the defaults and let the create method create the project.task.recurrence record and set the recurrence_id opw-5925546 Forward-Port-Of: odoo/odoo#249104
This update resolves an issue preventing users from creating new journals when a previously archived default account was linked to a journal. Previously, the system blocked new journal creation due to a uniqueness check that included archived accounts. Now, users can create new journals seamlessly, even with archived accounts, improving workflow efficiency.
Original PR description
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a…
Backport of https://github.com/odoo/odoo/pull/249869 Description This PR addresses a critical validation issue in the accounting module where the system blocks the creation of new journals if a default account linked to an existing journal has been archived. Current Behavior Currently, when a user creates a new journal (e.g., a "Bank" type journal), the system automatically generates or assigns a default account. If the user subsequently archives that default account, any future attempt to create a new journal of the same type results in a Validation Error: "Account codes must be unique. You can't create accounts with these duplicate codes: [XXXXXX]" This happens because the system's uniqueness check for account codes includes archived accounts, but the automated journal setup logic fails to account for this state, effectively locking the user out from creating new journals until the archived account is manually renamed or unarchived. Desired Behavior After this PR is merged, users should be able to create new journals seamlessly, even if previous journals have archived default accounts. video https://drive.google.com/file/d/1VzAskdTwF7lNc1y8PIpvN0T2zzKTMtdJ/view Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251025
This update addresses a visual issue where blank space appeared in activity cards after a description was cleared. The fix ensures that the activity note is only displayed when there's actual content, resulting in a cleaner and more professional user interface. This improves the overall user experience.
Original PR description
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note,…
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note, resulting in unnecessary blank space in the activity card. **Current behavior before PR:** Even when the activity description is cleared and contains only empty HTML, the activity note container is still rendered, leaving visible empty space in the UI. **Desired behavior after PR is merged:** The activity note is rendered only when it contains meaningful content. Empty HTML descriptions are ignored, preventing blank space from appearing in the activity card UI. Before <img width="445" height="84" alt="image" src="https://github.com/user-attachments/assets/f6648bb0-78d9-4063-a347-fe664370106e" /> After <img width="459" height="72" alt="image" src="https://github.com/user-attachments/assets/84c2063a-7c68-4dfe-b729-566ca4b5dcd1" /> task-[4752613](https://www.odoo.com/odoo/project/1519/tasks/4752613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252139
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 the map, ensuring it consistently 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 generating VAT reports (FAIA) for invoices in different currencies caused a rendering error. The fix ensures the necessary currency information is included in the report template, allowing accurate reporting across multiple currencies. This improves the reliability of VAT reporting for Luxembourg companies.
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 fixes an issue where analytic distribution wasn't being correctly passed from sales orders to purchase orders. Now, when a sale order with analytics is confirmed, the correct distribution is automatically applied to the corresponding purchase order, ensuring accurate cost tracking for inventory. This improves financial reporting and inventory management.
Original PR description
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 -…
Steps to reproduce: - Enable analytic distribution in Accounting settings - Create a storable product "P1": - Routes: MTO + Buy - Vendor: add any supplier - Create a Sale Order: - Add 1 unit of P1 - Set any analytic distribution - Confirm the Sale Order Result: A Purchase Order is created, but the analytic distribution is not propagated to the purchase order line. Problem: When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered. It creates and confirms the corresponding stock move with values from the sale order line. Since the product uses the MTO route, the procurement rule is executed. The rule prepares procurement values from the stock move, but the analytic distribution is not included in these values: https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539 Later, `_run_buy` is triggered. It uses the procurement values coming from the stock move to find an existing purchase order line candidate or to create a new one. Because the analytic distribution is missing from the values, the created (or matched) purchase order line does not contain the analytic distribution: https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113 Solution: Propagate the analytic distribution from the sale order line through the stock move so it can be included in the procurement values and correctly applied to the purchase order line. opw-5936971 Forward-Port-Of: odoo/odoo#252577 Forward-Port-Of: odoo/odoo#252292
This update resolves an issue where users with limited accounting access couldn't successfully import vendor bills via XML. The fix involves a change in how Odoo assigns data to ensure restricted users receive appropriate error messages when attempting to import, preventing unexpected behavior. This improves data integrity and security.
Original PR description
[FIX] account_edi_ubl_cii: restricted access user cannot import bill To reproduce: - create a user that has readonly access in Accounting - try to import a XML in vendor bills -> should traceback This commit modifies the `res_field` assignation by setting both `res_model` and `res_id` at the same time Forward-Port-Of: odoo/odoo#254698
This update fixes an issue where overtime calculations were inaccurate after employees switched their leave status between 'draft' and 'validated'. The system now automatically recalculates overtimes whenever leave information is updated, ensuring accurate overtime reporting. This prevents miscalculations and provides more reliable data for payroll and time tracking.
Original PR description
When we re-evaluate leaves we update overtimes after switching to draft but we do not update the overtimes again after the leave is switched back to validated. This causes the overtimes from attendances that overlap with the leave to be miscalculated as if the leave was not validated. To rectify this issue, we recalculate the overtimes for the affected employees after every create/write/unlink of `resource.calendar.leaves`. opw-4844447 Forward-Port-Of: odoo/odoo#253590 Forward-Port-Of: odoo/odoo#229723
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant function call, streamlining the process and ensuring accurate data import for our international customers.
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. The fix ensures that the system correctly retrieves purchase data, preventing future errors and maintaining data integrity. This resolves a problem impacting the reliable operation of the KE-EDI OSCO module.
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 an issue where quarterly VAT returns in Odoo Enterprise weren't automatically generating the necessary XML files for submission. The fix corrects a logic error that incorrectly used the return's start date instead of the end date for quarter detection. This ensures accurate XML generation and avoids return closure without the required export.
Original PR description
## Issue: When the tax return periodicity is set to quarterly and the return is validated, the XML file is not generated and downloaded ## Cause: The quarter detection logic was based on the `date_from` field of the return However, for quarterly returns, the correct reference should be `date_to` Using `date_to` also works correctly for monthly returns ## Steps to reproduce: - Install `l10n_it_xml_export` - Switch to the IT Company - Go in the Tax Report (Monthly VAT Report (IT)) to do a Tax Return (Opening Date: 01/01/2025, Periodicity: Quarterly) - If needed change the Tax Return Periodicity in Settings to Quaterly - Select the first report and ignore the error in Review Before the fix, it is only possible to close the return without generating the XML export opw-5707544
Documentation and clarification updates
This pull request formally welcomes Henry Backman from Camptocamp as a contributor to the Odoo project. The change is a legal confirmation (CLA) ensuring Camptocamp's compliance with Odoo's licensing terms. This integration allows Camptocamp to further develop and support the Odoo platform.
Original PR description
Please add me as a member of the Camptocamp organization. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254367
1 change
Resolved issues and error corrections
This update corrects a bug that caused incorrect decimal values to be generated in intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate intrastat reporting, improving data reliability for tax compliance.
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
1 change
Resolved issues and error corrections
This update corrects a bug in chart design that was introduced during a recent update. Previously, padding calculations weren't properly accounting for the new way chart titles are stored. This change ensures charts display with the correct padding, improving visual consistency and accuracy.
Original PR description
## Description Since the chart design refactoring, the value of the title is now stored in an object as chart.title.text, instead of the previous chart.title. During the introduction of the design customization, the computation of the padding hasn't been updated, considering now that the title is alsway defined, which is not the case. This PR aims to thix this behavior by changing the condition used in the padding computation. ## Related Tasks/PR: - Task: 0 - https://github.com/odoo/o-spreadsheet/pull/4385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
9 changes
New functionality added to Odoo
This update reflects changes in Belgian government regulations regarding the deductibility of certain expenses. The update modifies key fiscal category data (accounts 616580, 616541, 623610) to ensure accurate accounting and compliance with the latest tax rules. This ensures our Odoo Enterprise system aligns with current Belgian fiscal requirements.
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
Resolved issues and error corrections
This update corrects a minor issue where buttons within Helpdesk email templates were incorrectly identified as links, preventing them from functioning properly. The change ensures buttons are correctly recognized and handled by the editor, improving the user experience when interacting with tickets.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#110797 Forward-Port-Of: odoo/enterprise#107888
This update resolves a problem where the system incorrectly flagged invoices for EC Sales List compliance when customers were located within the EU. The fix ensures that the 'Only intra-EU customers' check accurately identifies invoices that violate EC Sales List regulations, improving data accuracy and compliance.
Original PR description
The EC Sales List return check "Only intra-EU customers" is reviewed when an invoice that match the condition for the warning same_country is present. To Reproduce: - Create a company in Belgium - Create a customer in Belgium with "Intra-Community" as a Fiscal Position - Create an invoice with this customer (in the previous month of the current month, for example February if the current date is in March - Open the Tax Returns - Open the EC Sales List Return - The Only intra-EU customers check is reviewed when it should show an anomaly. Forward-Port-Of: odoo/enterprise#107137
This update resolves an issue that was preventing users from copying spreadsheets within the Enterprise edition. The fix corrects a technical error that disabled the copy button, ensuring users can now seamlessly duplicate spreadsheets as needed. This improves workflow efficiency.
Original PR description
Fix error which disabled the copy button. Forward-Port-Of: odoo/enterprise#110700 Forward-Port-Of: odoo/enterprise#110086
This update resolves an issue where incorrect decimal values were appearing in Intrastat XML reports for French companies. The fix corrects a processing error that occurred when handling numerical data, ensuring accurate reporting of intrastat values. This improves the reliability of our French Intrastat reporting 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 fixes a bug that caused invoices sent to the Colombian DIAN tax authority to be incorrectly rejected as duplicates. When the DIAN GetStatus endpoint failed, the system would roll back the invoice state, leading to duplicate submissions. This change ensures the invoice state is correctly recorded, preventing these errors and improving DIAN invoice processing.
Original PR description
Steps to reproduce:
- Send a Colombian DIAN invoice (SendBillSync flow)
- Simulate a non-200 response from the DIAN GetStatus endpoint during the call of _get_attached_document (see ticket)
Issue:
The invoice is accepted by DIAN but the state is never written. When trying to send the invoice a second time DIAN rejects the invoice as a duplicate (already submitted).
Cause:
`_get_response_history` returns `("", error_msg)` on non-200 status_code and when calling `_get_attached_document`
-> error and rollback and `invoice_accepted` is not written correctly
opw-5919395This update fixes an issue in the Spanish balance sheet reports where retained earnings were incorrectly excluded, potentially leading to inaccurate equity calculations. The change ensures that all relevant equity accounts are included, maintaining consistent and reliable equity totals.
Original PR description
Description of the issue this commit addresses: The ES balance sheet “prior periods” line only matched code 12, so retained/unaffected earnings posted on other codes were skipped, which could understate or skew equity totals. --- Desired behavior after this commit is merged: The line now includes both accounts with code 12% and accounts of type equity_unaffected, so carried-forward results are always included and equity totals stay consistent. --- task-6047627
This update resolves a potential issue where the system couldn't correctly evaluate certain data types within the industry_fsm module, specifically impacting project task management. The fix ensures that all values passed to the `literal_eval` function are strings, preventing errors and improving data processing reliability.
Original PR description
literal_eval needs string values to evaluate,
action.get('domain', []) returns non-string value.Features or functions removed from Odoo
This update streamlines the process for certified scales in Point of Sale by removing unnecessary tare management features. The focus is now solely on the dedicated scale tare button, aligning with requirements for LNE certification. This change improves the user experience and prepares the system for scale certification compliance.
Original PR description
This PR removes the tare managing from Point Of Sale for the certified scales, leaving its management for the scale tare button and prepares the v19.0 for the certification of the scales with LNE Community PR: https://github.com/odoo/odoo/pull/253328 <img width="1192" height="956" alt="image" src="https://github.com/user-attachments/assets/0057d2dc-f8ae-4f17-83ad-940398e65224" /> <img width="796" height="661" alt="image" src="https://github.com/user-attachments/assets/378a3dc6-ccb9-4142-85ac-e3ea71c75497" /> <img width="294" height="849" alt="image" src="https://github.com/user-attachments/assets/03d783b1-70cb-4c38-b827-b75c59c0fc29" /> task-5977538
8 changes
Resolved issues and error corrections
This update fixes a potential server error that could occur when checking the status of batch payments. Previously, an error would display to the user, but now the system gracefully handles authentication issues and redirects the user to reconnect, improving the payment process reliability.
Original PR description
**Steps to reproduce:** 1. Install module `account_online_payment` 2. Go to Invoice > Payment, create payment, set partner and amount, then confirm 3. Go to Batch Payments and create a batch, set the bank and add the payment 4. From batch payment list view, select batch and click "Check Status" action **Issue:** Checking the status of a batch payment may raise a traceback with `OdooFinRedirectException`. **Cause:** `check_online_payment_status` calls `_fetch_odoo_fin` to retrieve the payment status. When the online account needs re-authentication, `_handle_response` raises `OdooFinRedirectException`. Since this exception is not handled, it propagates and results in a server error. **Fix:** Catch `OdooFinRedirectException` in `check_online_payment_status` to handle exception so that, user is redirected to reconnect the online account instead of seeing a traceback. **opw-5961729**
This update fixes a bug in the General Ledger CSV export by adding an initial balance line. It also corrects rounding logic to ensure currency conversions are accurate, improving the reliability of financial reporting data. This ensures more precise and complete financial reports.
Original PR description
1) 8dfe4c06106029f3f8039afc863bcacf7057106f added a csv export ledger for the general ledger, but it doesn't handle the initial balance. The fix is to call `_get_initial_balance_values` in the export method, as the query doesn't compute the initial balance lines. 2) Also changing the rounding logic, as currently the currency used is always the company currency, but for `amount_currency` it should use `currency_id`. task-5734354 Forward-Port-Of: odoo/enterprise#108344
This update corrects an issue with the numbering of report lines within the Vietnamese Balance Sheet report. Specifically, the section 'I. Short-term liabilities' now displays correct sequential numbering. This ensures accurate and consistent reporting 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
This update resolves an issue where accounting calculations in the l10n_mx_edi_pos module were inconsistent with Python computations. The fix ensures accurate amounts are displayed in the POS, aligning with the expected financial reporting. This improves the reliability of sales transactions for Mexican businesses using this module.
Original PR description
Before this commit, the needed assets were not correctly loaded in the POS, which caused the amounts to be different from the ones computed in python. opw-5970322
This update resolves an issue where the WhatsApp integration would crash when a WhatsApp Business Account was linked to multiple phone numbers. Odoo's design allows for this, but the webhook processing logic was flawed, causing a security error. This fix ensures the WhatsApp integration remains stable and reliable for users managing multiple WhatsApp Business Accounts.
Original PR description
The webhook crashes when a WhatsApp Business Account uses multiple phone numbers. ### Steps to reproduce 1. Link two phone numbers to the same Account ID. 2. Receive a webhook for that account. ### Cause Odoo allows multiple records to share one Account ID to support multiple phone numbers. When a webhook arrives, searching by this ID returns a of all 2 matching records. The system crashes because it tries to read a security secret from this recordset to verify the request. opw-5419180
This update corrects a technical error in how images are displayed within Odoo's reports. The fix ensures that image URLs are correctly processed, resolving a potential display issue. This improves the overall quality and reliability of Odoo reports.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update resolves a memory issue that occurred when propagating deliveries across multiple lots, particularly those with a large number of related picking IDs. The fix prevents a crash when handling large datasets, ensuring smooth operation for warehouses with extensive inventory.
Original PR description
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents. - Updating parent sets in a single operation caused a MemoryError for large datasets. ```sql…
- Some lots were found to contain very large delivery sets (7k+ picking IDs) with multiple parents.
- Updating parent sets in a single operation caused a MemoryError for large datasets.
```sql
Traceback (most recent call last):
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 333, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 346, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 506, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpe5fq5baf/migrations/base/tests/test_mock_crawl.py", line 539, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3858, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4089, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7078, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1311, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1493, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 442, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5297, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 149, in _compute_delivery_ids
delivery_ids_by_lot = self._find_delivery_ids_by_lot_iterative()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_lot.py", line 385, in _find_delivery_ids_by_lot_iterative
delivery_by_lot[parent_id].update(delivery_by_lot[lot_id])
MemoryError
(Pdb)len(all_lot_ids)
22166
(Pdb)len(barren_lines)
9682
(Pdb)len(lots_to_propagate)
9682
Lot_id 11412: delivery_by_lot size = 7420, parents = 3
Lot_id 11753: delivery_by_lot size = 0, parents = 7
Lot_id 12845: delivery_by_lot size = 11, parents = 5
Lot_id 14646: delivery_by_lot size = 12, parents = 2
Lot_id 15801: delivery_by_lot size = 1700, parents = 3
Lot_id 19817: delivery_by_lot size = 0, parents = 4
Lot_id 22370: delivery_by_lot size = 0, parents = 1
Lot_id 25072: delivery_by_lot size = 6827, parents = 2
Lot_id 25134: delivery_by_lot size = 3, parents = 2
Lot_id 25135: delivery_by_lot size = 1, parents = 2
```
- Previous fix adds all child deliveries, even if some already exist, but this new patch adds only the missing ones
UPG - 3869661
OPW - 5900313
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248826This update fixes an issue where the cash difference report in Point of Sale was inaccurate. The fix ensures the starting cash amount is correctly used, providing a more precise calculation of cash discrepancies. This improves the reliability of financial reporting for PoS transactions.
Original PR description
**Steps to reproduce:** - Open the PoS, input 100 as starting cash amount - Make a Sale for $70 and pay in cash - Close the PoS and input 170 as ending cash while closing the session - Open the PoS again, input 100 as starting cash - Close the PoS without making any sale and input 100 as closing cash - Go to the session reports for the last session - The **Difference** is wrong **Why the fix:** Before this commit, when closing the session without making any sale, the starting cash amount was set to the ending cash amount from the last session. This means that the input from the user at the begining of the session was not taken into account. We now use the starting cash instead of last session's ending cash. We also display the correct amount in the 'Cash Opening' section. opw-5391239
6 changes
Enhancements to existing features
This update relaxes a previous restriction, allowing employees to create leave requests even if payroll data is present for the period. This change ensures greater flexibility in managing employee time off, particularly in scenarios where continued pay percentages are fully utilized. It simplifies the process for creating leave while maintaining accurate payroll calculations.
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
Resolved issues and error corrections
This update fixes an issue where tax reports were incorrectly calculating period boundaries, leading to inaccurate reporting figures. The change ensures that the correct tax period is used for calculations, particularly when dealing with trimester-based tax periods, improving the accuracy of financial reports.
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 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.
This update corrects a visual issue where the company header in accounting reports appeared grayed out in dark mode. The change ensures consistent color styling by updating the header's color to match other muted data elements, improving the user experience across both light and dark themes.
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
This update fixes a technical issue with how images are displayed in Odoo reports. Specifically, a mistake in the way image URLs were handled was corrected, ensuring images are now rendered correctly across various reports. This improves the visual quality of reports for users.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update resolves an issue where importing Peppol bills with lines lacking names would cause an error in the system. The fix ensures the system can handle bills with unnamed lines, preventing import failures and improving data import reliability. This impacts the process of receiving and recording invoices from external suppliers.
Original PR description
**PROBLEM** When importing a peppol bill, if the partner have bills with unnamed lines there is a traceback. **STEP TO REPRODUCE** 1. Download the xml attach to the ticket. 2. Go to Accounting/Vendors/Bills, and upload it. 3. modify the Bill, removing the labels on the line so they are unnamed. 4. Upload the xml one more time, to create a new bill. 5. You should have a traceback. opw-6022549
This pull request includes a series of bug fixes and improvements across various Odoo modules, focusing on stability and performance. Key changes include addressing UI issues in the web editor, resolving invoicing errors, and enhancing localization support for multiple languages and regions. The update also incorporates improvements to the core system's installation process.
Original PR description
- **[IMP] *: disable auto-install** - **[IMP] google_gmail, web_unsplash: disable auto_install** - **[IMP] OCB README** - **[ADD] setup: support PEP 660 and setuptools >= 64** - **[FIX]…
- **[IMP] *: disable auto-install**
- **[IMP] google_gmail, web_unsplash: disable auto_install**
- **[IMP] OCB README**
- **[ADD] setup: support PEP 660 and setuptools >= 64**
- **[FIX] hr_recruitment, hr_recruitment_sms: bridge module**
- **[IMP] *: More auto-install disablings**
- **[FIX] account_edi_ubl_cii: remove ensure_one call in api.model**
- **[FIX] web_editor: removing icon makes paragraph unreachable**
- **[FIX] web_editor: enter before icon element**
- **[FIX] website: block Escape key on cookies bar**
- **[FIX] account_edi_ubl_cii: fix invoice address in ubl files**
- **[FIX] {sale_,}mrp: rounding on product packaging quantity**
- **[FIX] point_of_sale: closing balance count with rescue sessions**
- **[FIX] l10n_sa: fixing invoice issue time format in qr code**
- **[FIX] account_edi_ubl_cii: use the right VAT when exporting invoices**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] web_editor: open a popover for inline document download**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: export 17.0 source terms**
- **[PERF] bus: tweak acquire cursor delay**
- **[PERF] bus: improve cursor usage efficiency**
- **[FIX] bus: explicit close for notif sockets**
- **[FIX] bus: do not terminate twice**
- **[FIX] hw_drivers: allow upgrades to >= 19.1**
- **[FIX] l10n_vn: Add Vietnamese translations for tax fields**
- **[IMP] l10n_br: add new master data for Brazilian fiscal reform**
- **[FIX] bus: race between terminate and notification dispatching**
- **[FIX] point_of_sale: fix crash when switching tab while printing receipt**
- **[FIX] {account_,}payment,sale: set correct message author**
- **[FIX] website: fix incorrect <p> wrapping for custom button snippet**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] mail: avoid error on service worker push subscription change**
- **[FIX] mail: `ir_cron_web_push_notification` are now more robust**
- **[FIX] mail: `push_to_end_point` method to support `.invalid` TLD.**
- **[FIX] mrp: unlink irrelevant move raws on bom update**
- **[IMP] account_edi_ubl_cii_tax_extension: optional tax exemption reason**
- **[FIX] discuss: increase the ping tolerance for rtc sessions**
- **[FIX] mail: Fix truncate all related table data**
- **[FIX] payment_stripe: enable stripe connect for french territories**
- **[FIX] payment: fix name splitting logic for single-word names**
- **[IMP] hw_drivers: normalise logs around actions**
- **[FIX] account_edi_ubl_cii: prioritize partner legal entity name**
- **[FIX] l10n_vn_edi_viettel: wrong exchange rate when issue foreign**
- **[FIX] account: allow duplicating entries with deprecated accounts**
- **[FIX] website_sale: filter unavailable providers for website in sales portal**
- **[FIX] l10n_fr_hr_holidays: missing default reference leave type in setting**
- **[FIX] hr_holidays, hr_work_entry_holidays: leave with changing calendar**
- **[IMP] core: Fully comply PDF/A-3A on all supported pypdf versions**
- **[FIX] loyalty: Mark service product noupdate**
- **[FIX] l10n_es_edi_verifactu_pos: ensure qr-code is present on order reprint**
- **[FIX] website: preserve custom height on image gallery**
- **[FIX] hw_drivers: tailscale compatible upgrade**
- **[FIX] point_of_sale: guarantee payments order in sales details report**
- **[FIX] base: the .1s timeout in the SMTPD tests is overly conservative**
- **[FIX] sale: prevent invoice_origin from being copied via Invoices smart button**
- **[FIX] website: prevent blurry countdown canvas and text on zoom**
- **[FIX] web_editor: prevent text overlap with icon**
- **[FIX] base: disable session saving on /web/image to prevent logout on Firefox**
- **[FIX] account: adapt how account statement validity is computed**
- **[FIX] mail: fix incorrect avatar display**
- **[IMP] mail_plugin: allow the mail plugin to know the Odoo version**
- **[FIX] spreadsheet: update o_spreadsheet to latest version**
- **[FIX] l10n_br: fix tax names**
- **[FIX] *: api keys group managment**
- **[IMP] l10n_fr: MOA value should be positive**
- **[FIX] l10n_es_edi_verifactu_pos: apply simplified invoice limit in VeriFactu POS**
- **[FIX] mail: mail.message create on no user**
- **[FIX] web: prevent automatic conversion of `B)` to 😎 emoji**
- **[FIX] account: Remove sudo-ed returned bank**
- **[FIX] base_automation: keep to compute values in pre-filter**
- **[FIX] repair: preserve discount on sale order line from repair quotation**
- **[IMP] hr_expense: use payment_reference for payment term line name**
- **[FIX] l10n_es_edi_facturae: fix issuer generation**
- **[FIX] l10n_fr: wrong aggregation**
- **[FIX] account: Fix _aggregate_taxes with multi rep lines taxes**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] base: add help attribute on field element in rng validation**
- **[FIX] purchase_stock: prevent compensation aml when PO other currency**
- **[FIX] sale{,_management}: hide update prices button when no pricelist is set**
- **[FIX] l10n_fr: small errors**
- **[IMP] uom, account{_edi_ubl_cii,}: add 2 UoM from UNECE Recommendation No.20**
- **[FIX] website: properly mock Clipboard API calls in tours**
- **[FIX] account: prevent posting with inactive analytic accounts**
- **[FIX] mail: avoid trying to send scheduled notifications for deleted records**
- **[FIX] mail: hide message failures for deleted records**
- **[FIX] mail: fix management of activities on removed records**
- **[FIX] base: set Bulgaria currency to EUR**
- **[FIX] hr_attendance: prevent a user from updating their attendance record by changing the employee to the one whose attendance is not managed by the current user.**
- **[FIX] hr_expense: include all attachments in generated journal entries**
- **[FIX] portal: link preview triggering page view**
- **[IMP] l10n_fr_facturx_chorus_pro: add Chorus fields to invoice PDF**
- **[IMP] account_edi_proxy_client,*: move unique edi_id constraints**
- **[FIX] account: fix invoice_origin missed in reverse move**
- **[IMP] mail: add missing docstrings for message access**
- **[FIX] mail: correctly check message / document access**
- **[FIX] mail: make _search symetric to read**
- **[FIX] mail: make message search / read coherent for portal**
- **[MOV] mail: add helper for '_get_mail_message_access' usage**
- **[FIX] mail: make activity schedule coherent with mail posting**
- **[FIX] mail: correctly check for post capabilities in discuss**
- **[FIX] website_crm_partner_assign: fix portal chatter**
- **[FIX] mail: fix undefined variable**
- **[FIX] mail: handle wildcard content-type**
- **[FIX] website: only update menu on page creation if the menu has no page**
- **[FIX] l10n_it: migrate from 16.0 without l10n_it_exempt_reason column**
- **[FIX] l10n_latam_invoice_document: get sequence when prefix has numbers**
- **[IMP] account_edi_ubli_cii: Split fixed taxes into allowance charges or additional invoice lines.**
- **[FIX] l10n_it_stock_ddt: generate DDT before completing the picking action**
- **[CLA] Individual CLA signature**
- **[FIX] pos_loyalty: fix saved orders point**
- **[IMP] account: Use invoice_label for tax name in invoice tax computation**
- **[FIX] auth_signup: signup_cancel as sudo when writing on active**
- **[FIX] spreadsheet: update o_spreadsheet to latest version**
- **[FIX] sale_stock: include cogs credit note after downpayment**
- **[FIX] pos_sale: prevent spliting by lots when product is kit**
- **[FIX] web: show scanned barcode for iOS**
- **[FIX] website_slides: prevent error in back button**
- **[IMP] base: update thailand state names**
- **[FIX] hr_attendance: compute company tolerance when multiple attendances**
- **[FIX] pos_loyalty: increase barcode width**
- **[IMP] crm_iap_mine: change leads mining provider to dnb**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[IMP] event_sale: Do not confirm registrations for paid events when the sale is confirmed.**
- **[CLA] Sign CLA for p4v3**
- **[FIX] microsoft_calendar: make Graph timeout configurable**
- **[FIX] purchase: correct POL unit price via catalog**
- **[FIX] bus: fix pool error on server stop**
- **[FIX] website_sale, fixing test**
- **[FIX] hr_holidays : Create allocation with same number of hours**
- **[IMP] l10n_ro: add missing tax mappings for new VAT rates**
- **[FIX] account_edi_ubl_cii: fix cases where VAT is '/'**
- **[FIX] l10n_ch: fix negative values in VAT report figures 382a and 383a**
- **[FIX] base: prevent error when unarchiving company**
- **[IMP] account_edi_ubl_cii,*: backport accounting test helpers**
- **[FIX] account: strip out dots from VAT numbers**
- **[FIX] l10n_id_efaktur_coretax: Fix tax group restriction in efaktur coretax**
- **[FIX] l10n_sa: fix timezone**
- **[IMP] spreadsheet: log data extraction**
- **[I18N] l10n_{cy,gr}: fix Greek language code**
- **[I18N] .weblate.json: add missing modules**
- **[FIX] web_editor: allow non-admin editor user to save Unsplash image**
- **[FIX] mail: typo in search_highlight tests**
- **[FIX] l10n_es_edi_verifactu: restrain certificate access**
- **[FIX] base: prevent server crash on malformed module description**
- **[FIX] account_peppol: safer server deregistration**
- **[PERF] bus: use orjson for faster notification serialization**
- **[FIX] mail: show explicit error of fetch message in message list**
- **[FIX] spreadsheet: update o_spreadsheet to latest version**
- **[FIX] *: Fix json decode error imports**
- **[FIX] stock_delivery: correctly compute package/picking shipping weight**
- **[FIX] maintenance: fix high-priority maintenance request count**
- **[FIX] pos_self_order: fix empty order lines check before printing changes**
- **[FIX] product: prevent infinite loop in `_cartesian_product`**
- **[FIX] point_of_sale: ensure product is loaded before refunding orderline**
- **[FIX] point_of_sale: prevent rounding issues in cash difference removal**
- **[FIX] l10n_ar: taxes 0% NT/NA/EXEMPT amount type**
- **[FIX] web: Support reserved words as customer names**
- **[FIX] account_edi_ubl_cii: fix duple attachment bug**
- **[FIX] l10n_id: fix 1.3 migration script**
- **[IMP] crm_iap_mine: remove redundant fields in mail template**
- **[FIX] *: replace "Deco Addict" with "Acme Corporation"**
- **[FIX] account: make "sample" invoices demo-only**
- **[FIX] sale: prevent payment when so is expired**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: add new language files**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] account_edi_ubl_cii: set imported partner as company**
- **[FIX] base/ir.ui.view: keep tail when remove the field from access group**
- **[FIX] l10n_fr_fec: reduce FEC export memory footprint**
- **[FIX] hr_homeworking: send current day location field in get_views**
- **[FIX] survey: prevent hiding timer in live session**
- **[FIX] account_peppol: neutralize should be consistent**
- **[FIX] mrp_subcontracting{,_purchase}: fix inconsistency between stock move and move line quantities**
- **[IMP] l10n_sa_edi: zatca onboarding bugprovement**
- **[FIX] tests: WebGL disabled in Chrome Headless 144+**
- **[FIX] hr_holidays_attendance, hr_attendance: include attendance between two days in hourly accrual plans**
- **[FIX] sale: use single wizard.res_id in compute_warning**
- **[FIX] hr_attendance: prevent multiple check-ins/outs and geolocation hang**
- **[FIX] mrp: fix ongoing timer for deleted work orders**
- **[FIX] tools: align policy addition API**
- **[FIX] microsoft_calendar: support single-tenant apps**
- **[FIX] website_sale: make test demo-data-independent again**
- **[FIX] account: prevent crash when selecting tax in journal item dialog**
- **[PERF] account: speed up _get_total_amount_using_same_currency**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[CLA] Update for Moduon**
- **[REF] microsoft_calendar: rename test method**
- **[ADD] l10n_ro_cpv_code: A new module to add a new filed 'CPV' code in product**
- **[FIX] hr_recruitment: fix Unable to Send Emails to Refused Applicants**
- **[FIX] discuss: update the sfu bundle to v1.3.3**
- **[FIX] mail: prevent enabling tracking on HTML fields**
- **[FIX] web_editor: prevent error when saving after applying history**
- **[FIX] l10n_ro_efactura: Allow reset to draft for e-bills**
- **[FIX] l10n_it: Wrong exoneration code on 0% EU S**
- **[FIX] point_of_sale: close session with SEPA first payment method**
- **[FIX] hr_skills: prevent duplicate skill creation after validation error**
- **[FIX] l10n_cy: correct vat payable/refundable formula**
- **[FIX] account_edi_ubl_cii: fix EPD on credit notes**
- **[FIX] website_sale: adapt checkout color contrast**
- **[FIX] repair: cancel draft stock moves on repair order deletion**
- **[IMP] base_vat: use dummy tax for Türkiye placeholder ID**
- **[FIX] account_peppol: prevent invoice reset to skipped**
- **[FIX] spreadsheet: update o_spreadsheet to latest version**
- **[FIX] account: allow translation reload without all companies**
- **[FIX] odoo: scope zip_dir**
- **[FIX] mail: mention suggestion prioritizes followers over recent chats**
- **[FIX] mail: fix style of mention suggestion**
- **[FIX] mrp: ensure variant synchronization in BoM report**
- **[IMP] account: simplify switching move type**
- **[FIX] mail: properly sort mention suggestions in the full composer**
- **[FIX] website: keep all parameters on force redirect**
- **[FIX] l10n_es: fix mod 390 computation**
- **[FIX] peppol_proxy: Peppol - don't recommend technical contact for support**
- **[FIX] account_edi_ubl_cii: do not import info on vendor refund**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: export 17.0 l10n source terms**
- **[IMP] test_mail: add performance test for message access**
- **[FIX] mail, various: improve prefetching in message access**
- **[IMP] test_mail: improve msg/activity test access coverage**
- **[FIX] mail: correctly support document message access for activities**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: add new language files**
- **[FIX] project: set correct action target of project window**
- **[IMP] l10n_ro_stock_edi: eTransport improvements**
- **[FIX] purchase_mrp: UoM category error on kit**
- **[FIX] point_of_sale: prevent unfocused input when popup is open**
- **[FIX] account_edi_ubl_cii: log the account numbers**
- **[FIX] account_peppol: allow PEPPOL with audit trail**
- **[FIX] l10n_fr_fec: use correct company when downloading FEC file**
- **[REV] account_edi_ubl_cii: log the account numbers**
- **[FIX] account: disallow untrusted accounts on is_inbound() invoices + log bank account**
- **[FIX] l10n_it_edi: propagate l10n_it on create_company**
- **[IMP] partner_autocomplete,iap_mail: company info in chatter**
- **[FIX] l10n_it_edi: display TC-XX codes for funds**
- **[FIX] calendar: preserve duration when editing quick-created events**
- **[FIX] l10n_it_edi: fix import of cross-company products**
- **[FIX] l10n_sa_edi: converted amount in invoice report**
- **[FIX] stock: prevent traceback when generating serial/lot numbers**
- **[FIX] l10n_es: fix report mod 390**
- **[FIX] website: test_website_force_domain_redirect works w/o demo**
- **[IMP] profiler: Time limit to commit profile**
- **[FIX] tools: never consider a node with a directive as translatable**
- **[FIX] account: portal bill report no proforma**
- **[FIX] hr_attendance: fix access issue**
- **[FIX] account: remove comments while parsing XMLs**
- **[FIX] core: unsafe attributes are privates**
- **[FIX] account_edi_ubl_cii: Don't import null LineExtensionAmount lines**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] account: Add Filter to support selecting multiple journals**
- **[FIX] core: superfluous image processing**
- **[FIX] sale_project: unlink SO when no SO item is linked to a task**
- **[FIX] hr_expense: skip encrypted files from expenses report PDF**
- **[FIX] hr_holidays: fixing leave days allocation use priority**
- **[FIX] web: correct autoresizeInput width calculation**
- **[FIX] web_editor: properly parse pasted XML in email templates**
- **[FIX] website_sale: prevent double delivery amount in express checkout**
- **[IMP] web: update owl to 2.8.2**
- **[IMP] l10n_in: change GSP provider for Indian EDI**
- **[FIX] account_peppol: use correct company context**
- **[FIX] l10n_it_edi: make OSS flow compliant with FatturaPA**
- **[FIX] website, web_editor: only translate views for websites**
- **[REF] web_editor: refactor `WebP` to `JPEG` conversion in upload service**
- **[FIX] web_editor: fix image upload error handling**
- **[FIX] hw_drivers: fix SSL verification for IoT handlers**
- **[FIX] website_sale_loyalty: prevent random shop_sale_ewallet tour failure**
- **[FIX] l10n_it_edi: fix total in company currency**
- **[FIX] hr_attendance, hr_holidays_attendance: update overtimes after reevaluating leave**
- **[IMP] account_edi_ubl_cii: Identify the correct tax at import**
- **[FIX] l10n_sa_edi_pos: prevent error when order has no payment**
- **[FIX] core: missing type check**
- **[FIX] hr_skills: random runbot tour failure**
- **[FIX] survey: use answer token in cookies**
- **[FIX] account: beneficiary account can be incorrect after payments merge**
- **[FIX] point_of_sale: filtering single attribute value products**
- **[FIX] l10n_de: ensure pdf rendering in audit trail test**
- **[FIX] l10n_it_edi: forfettari can now use simplified invoices freely**
- **[CLA] Signature for blackne0n**
- **[FIX] l10n_hu_edi: ensure softwareId meets NAV 18-character requirement**
- **[IMP] core: -t alias for --test-tags**
- **[IMP] account_edi_ubl_cii: (un)group lines by tax**
- **[FIX] hr_expense: skip encrypted files from expenses report PDF (2)**
- **[FIX] account: inherit product category accounts from parent hierarchy**
- **[FIX] account{_peppol,_edi_ubl_cii,}: allow sending via Peppol after PDF or XML generation**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] base_vat: catch broader exceptions in VIES check**
- **[FIX] lunch: prevent order_lunch_tour failure**
- **[FIX] website: prevent random link_tools tour failure**
- **[FIX] l10n_bg: fix tax names and default purchase tax**
- **[FIX] l10n_ro: fixed romanian tax report**
- **[FIX] l10n_ro: Add the "active" column to the account taxes**
- **[FIX] pos_sale: consider the lot location in pos**
- **[FIX] account: allow child companies to use parent contacts**
- **[IMP] account_edi_ubl_cii: update factur-x/zugferd**
- **[FIX] portal: set dir attribute on html element**
- **[IMP] account: add ZIP export for move attachments**
- **[FIX] hr_skills: show traceback when downloading resume with invalid template**
- **[FIX] hr: use action_archive in departure wizard**
- **[FIX] l10n_sa{_edi}: fix future invoicing bug**
- **[FIX] base: correct Qatar currency label**
- **[I18N] base: re-export pot file**
- **[FIX] sale: fix status order in sales kanban view**
- **[FIX] crm_iap_mine: Handle no credit properly**
- **[FIX] core: hide ConnectionLostError after tour termination**
- **[FIX] core: hide AssetsLoadingError after tour termination**
- **[FIX] hr_holidays_attendance: restore removed method and set deprecated**
- **[FIX] account_edi_ubl_cii: avoid potential KeyError**
- **[IMP] account: remove friction when using untrusted company account**
- **[IMP] account,l10n_ch,base: unify bank creation**
- **[FIX] account_edi_ubl_cii: set the account numbers**
- **[CLA] mega-ramo Signature**
- **[IMP] core: don't spam waiting for threads if there are none**
- **[IMP] core: backport neutering of password hash during tests**
- **[IMP] base: lower log level of mail sending during tests**
- **[IMP] google_calendar: move data setup to setUpClass**
- **[IMP] point_of_sale: do the repetitive test setup at the class level**
- **[IMP] google_calendar, microsoft_calendar: lower spam during tests**
- **[IMP] core: add lru on `babel_locale_parse`**
- **[FIX] website: do not prefix `#top` and `#bottom` menu URLs**
- **[FIX] website: load empty iframes on Firefox 148**
- **[FIX] mrp: unlink only outdated workorders and moves on BoM update**
- **[FIX] stock: stock in transit from sublocation**
- **[FIX] pos_sale: amount_unpaid wrong computation**
- **[FIX] l10n_ro_cpv_code: Fix CIUSRO ItemClassificationCode/listID**
- **[FIX] portal: fix error 500 when info edit with no country**
- **[FIX] account: do not block incoming payments**
- **[IMP] account: include draft vendor bills in 'Unpaid' filter**
- **[FIX] website_slides: support Google Shared Drive links**
- **[FIX] web_editor: fix isDirty freezing the editor**
- **[FIX] l10n_hu_edi: Prevent tax audit export from setting invoice chain**
- **[ADD] account_peppol_selfbilling: Peppol Self-Billing backport**
- **[FIX] account_peppol: do not recompute EAS/Endpoint on registered companies**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] core: ensure non zero size for pdf attachment**
- **[REV] account_edi_ubl_cii: Partial revert of "Identify the correct tax at import"**
- **[FIX] account: `_user_can_trust` ensure one**
- **[FIX] l10n_it_edi_withholding: relax import tax check on withholding**
- **[FIX] l10n_it_edi_doi: Remove check on DOI tax being the only one on the line**
- **[FIX] account_edi_ubl_cii: EPD handling in factur-x**
- **[FIX] mail: ignore archived blacklists**
- **[FIX] pos_self_order: fix qr for pos_self_order**
- **[FIX] purchase: fetch discount from vendor in catalog**
- **[FIX] web_editor, mass_mailing: mark field dirty when leaving code view**
- **[FIX] auth_totp_portal: fix secret copy button**
- **[FIX] stock: Prevent RuntimeError on Transit from sublocation**
- **[FIX] sale_timesheet_margin: Timesheet cost compute**
- **[REV] account: portal bill report no proforma**
- **[FIX] account_edi_ubl_cii: automate bill line grouping**
- **[FIX] account_edi_ubl_cii: include sale moves and prevent duplicate PDF**
- **[FIX] base: find or create bank with company contact**
- **[FIX] microsoft_calendar: avoid recurring editing outlook for other users**
- **[FIX] l10n_my_edi: correct prepaid and payable amounts for specific document types**
- **[FIX] im_livechat: rephrase chatbot completion message in composer**
- **[FIX] point_of_sale: disallow multiple order by refund**
- **[FIX] stock: Improve error message on package consistency check**
- **[FIX] l10n_it_edi_ndd_account_dn: refactor typo for field DatiFattureCollegate**
- **[CLA] christian-ramos-tecnativa Signature**
- **[FIX] sale_stock: prevent unlink of sale order from delivery**
- **[FIX] core: warnings manipulations in vendored werkzeug.urls**
- **[FIX] base_vat: ensure valid NRI GSTINs are accepted**
- **[FIX] l10n_in_edi: error hide for second EDI**
- **[FIX] account{_edi_ubl_cii}: don't group lines at import if link with PO**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: add new language files**
- **[I18N] *: fetch latest Weblate translations**
- **[PERF] l10n_sa_edi: Optimize the sanity check of a journal for onboarding on ZATCA.**
- **[FIX] payment_razorpay: fix name with comma and long name issue**
- **[FIX] base_import: fix for import of some date like "2500/1222" guessed as "%Y.%m.%d" format**
- **[CLA] Update Vauxoo's CLA adding edy1192**
- **[FIX] mail: handle bin/plain attachments**
- **[FIX] account_edi{_ubl_cii}: fix UoM to UNECE code**
- **[FIX] stock_delivery: compute shipping weight on multiple pickings**
- **[FIX] base_import: better import info logs**
- **[FIX] point_of_sale: create move line for change when no cash pm**
- **[FIX] account_edi_ubl_cii: allow zero subtotal lines**
- **[FIX] account_edi_ubl_cii: zugferd xml name**
- **[ADD] l10n_dk_fik: Add Danish FIK payment reference on customer invoices**
- **[FIX] bus: send correct im_status when unlinking presence**
- **[FIX] project_timesheet_holidays: Only create timesheets for validated leaves**
- **[FIX] l10n_ar: allow "Export Invoices" document type for "IVA Sujeto Exento" companies**
- **[FIX] account_edi_ubl_cii: handle non-string regex**
- **[FIX] http: use urlsplit in redirect**
- **[FIX] sale_stock_margin: fix missing company context for _compute_average_price**
- **[CLA] Add CLA for Vedant Madane**
- **[FIX] base: fix Departement typo in country state help string**
- **[FIX] website: allow copyright bg color when footer has no bg color**
- **[CLA] Update Therp company CLA**
- **[FIX] point_of_sale: sort taxes before groupby in session load**
- **[FIX] mrp_account: normalize kit cost by bom.product_qty**
- **[FIX] account_edi_ubl_cii : manage charges in UBL docs**
- **[I18N] *: export 17.0 l10n source terms**
- **[I18N] *: export 17.0 source terms**
- **[I18N] *: fetch latest Weblate translations**
- **[I18N] *: fetch latest Weblate translations**
- **[FIX] l10n_in: prevent error when trying to merge multiple contacts**
- **[FIX] calendar: prevent mail defender from cancelling meetings**
- **[FIX] web: new File() should receive a correct mimetype**
- **[IMP] tests: adding environment variable for browser used in testing**
- **[FIX] partner_autocomplete: ensure valid NRI GSTINs are accepted**
- **[FIX] test: chrome littering**
- **[FIX] website*sale*: tours with translation error**
- **[FIX] account: reconciliation when writeoff is exchange account**
- **[IMP] l10n_ec: new withholding percentages for 2026**
- **[FIX] account: include missing company_dependent on avatax settings**
- **[PERF] stock: prevent MemoryError when running schedulers.**
- **[FIX] l10n_in_hr_payroll: relationship field shown to non-indian employee**
- **[FIX] resource: compute date_to from date_from on a resource time off**
- **[FIX] stock : Fix MemoryError in delivery propagation**
- **[FIX] calendar: add csrf token, use keepquery, remove decline url**
- **[FIX] website: restrict header border width to single value**
- **[FIX] l10n_sa_edi: include cash rounding line in payable amount**
- **[FIX] auth_oauth: USER_PRIVATE_FIELDS at uninstall**
- **[FIX] account: allow preview for invoice with early discount and no date**
- **[FIX] pos*: disable confirm button in `TextInputPopup` if input empty**
- **[FIX] l10n_it_edi: ignore product tax when importing vendor bill from XML**
- **[I18N] *: add missing modules to .weblate.json**
- **[17.0][FIX] stock _find_or_create_global_route search route name passing lang to context**
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