Daily updates from Odoo
Tuesday, November 25, 2025
267 changes
13 changes
Resolved issues and error corrections
This update resolves an issue preventing batch payments from correctly transitioning to 'reconciled' status, particularly when dealing with complex scenarios like early payment discounts and currency exchange differences. The fix ensures accurate reconciliation processing, streamlining the bank reconciliation workflow and improving financial reporting.
Original PR description
In the goal of fixing the batch payments with EPD in the bank rec widget, we discovered another bug that was preventing the batch payments to change their state to "reconciled". This was due to some compute not being triggered again when one of its dependences did change (during another compute). task-4681366 Forward-Port-Of: odoo/odoo#223310 Forward-Port-Of: odoo/odoo#222303
This update fixes how early payment discounts (EPD) are displayed in the bank reconciliation widget. It now accurately reflects EPD amounts when batch payments containing invoices are used, ensuring correct reporting of discounts and payments. This improves the accuracy of financial reconciliation processes.
Original PR description
In the bank reconciliation widget, it is now possible to have batch payments containing payments linked to only invoice_ids. Such batch payment, once mounted in the widget, should reflect the invoice or move amounts of its payments, and not only the payments amount. In the case of a payment-invoice combo that's elligible for an early payment discount, the early payment discount should also be displayed in the widget. Example: Invoice of 1000$ with possible EPD of 2%. A payment (with no move) is done (paid in the "early" period) for 980$. The payment is then put into a batch payment. Once in the bank rec widget, when mounting the 980$ batch payment to a statement line of 980$, the widget should display it as a batch payment line of 1000$ and add another 20$ Early payment Discount line. task-4681366 Forward-Port-Of: odoo/enterprise#92593 Forward-Port-Of: odoo/enterprise#83077
This update optimizes the Odoo stock module by preventing unnecessary processing when unpacking empty product packages. Previously, a slow function was triggered, impacting user request speeds. Now, the system avoids this delay, leading to a smoother and faster experience for users.
Original PR description
For an empty package the `quant_tasks` function will be executed without restriction of scope and can potentially slow the user request intensly. And if there is no quants in the package the tasks are not necessary. After the unpacking of the quants they are not in the package anymore. Causing the call to quant_tasks to be done on an empty recordset. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234370
This update fixes an issue where users were incorrectly changing product details on combo item lines. To address abuse of the system, a temporary workaround has been implemented requiring users to hide product fields before editing the description. This ensures data integrity within the sale order process.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes). Forward-Port-Of: odoo/odoo#237148 Forward-Port-Of: odoo/odoo#235547
This update corrects a bug that prevented purchase orders with warnings from appearing in reports. The change introduced an unintended inversion in the search logic, causing POs without warnings to be incorrectly displayed. This fix restores the expected behavior of showing POs with warnings, ensuring accurate reporting.
Original PR description
Steps To Reproduce ------------------ 1- To purchase orders 2- Create random purchase orders (with activity and without and with warning) 3- Select the Warning Filter Issue ----- 1- Only POs with no…
Steps To Reproduce
------------------
1- To purchase orders
2- Create random purchase orders (with activity and without and with warning)
3- Select the Warning Filter
Issue
-----
1- Only POs with no activities show on the list.
2- The behavior in versions previous to 18.3 works perfectly fine, showing only POs with warnings.
Cause
-----
The issue is caused by this commit: 92301a5b300dec1ddfca44dc35318b83d67c56fa.
The search logic for the activity_exception_decoration field was changed to refuse negative operators (`!=`):
https://github.com/odoo/odoo/blob/92301a5b300dec1ddfca44dc35318b83d67c56fa/addons/mail/models/mail_activity_mixin.py#L118-L121
This forces the ORM to invert the filter:
https://github.com/odoo/odoo/blob/9a8350cb476af73d6bf4eea75344963eac1c7831/odoo/orm/domains.py#L873-L880
For this case, this transforms the intended query:
`Exists(activity_exception_decoration != False)` ("Has Warning")
Into the inverted query:
`NOT Exists(activity_exception_decoration == False)` ("Does NOT have a Normal activity")
This incorrectly hides records that have both warning and normal activities, and incorrectly shows records with no activities at all.
opw-5177277
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236732This update resolves an issue where the base_import module would fail when unable to access the definition of a record. The fix now checks for group restrictions in addition to model access, preventing crashes and ensuring more reliable data imports. A new test case has been added to cover both scenarios.
Original PR description
…ible https://github.com/odoo/odoo/pull/236037 ignores the properties field if we don't have access to the definition model at all. However, we should also check field groups to avoid crashing if the user cannot access the definition field because of group restrictions. Forward-Port-Of: odoo/odoo#237166 Forward-Port-Of: odoo/odoo#236912
This update resolves an issue where changes to many2one fields within the website builder weren't correctly reflected in the sidebar. The fix ensures that the `data-oe-many2one-id` attribute is copied during replication, preventing incorrect data display and saving problems. This improves the accuracy of sidebar information.
Original PR description
When replicating changes from one field to other occurences of the same field in the document, the `data-oe-many2one-id` was not copied (for many2one fields). Thus it could lead to showing incorrect values in the sidebar, or saving them. This commit fixes that by adding a dispatch to handlers after the replication, and implementing a handler that copies the `data-oe-many2one-id` when needed. Steps to reproduce: - Open website builder on a blog post - Enable the "Sidebar" - Enable the "Author" in the sidebar - Click on the second occurence of the name of the author in the page - Change the "Contact" associated with the author of the post - Click on the first occurence of the name of the author in the page - Bug: the name of "Contact" is the old one - Change the "Contact" to yet another one - Save - Bug: the author is not the last one selected task-5252648
This update resolves a bug that occurred when translating content within the website editor. Specifically, adding a break element (BR) during translation caused save errors due to incorrect data handling. The fix ensures that translation branding is properly removed during non-translation mode, preventing these errors and improving website stability.
Original PR description
Scenario: - run Odoo with source code between [1] (29th october 2025) and [2] (19th november 2025) - translate a string in an embedded field with a BR added outside the translation contenteditable…
Scenario:
- run Odoo with source code between [1] (29th october 2025) and [2]
(19th november 2025)
- translate a string in an embedded field with a BR added outside the
translation contenteditable (eg. select completely a LI element and
replace the content by something else)
- save
- edit the content in source language, save (with or without any change)
Result: traceback error containing:
> File "addons/html_editor/models/ir_ui_view.py", line 66, in save_embedded_field
> model = 'ir.qweb.field.' + el.get('data-oe-type')
> ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
> TypeError: can only concatenate str (not "NoneType") to str
Cause:
Commit [1] removed o_editable on nodes that should not be editable, but
that caused those nodes to no longer have data-oe-readonly attribute.
When replacing the whole content translation node, the original content
is first removed, after which DeletePlugin.fillShrunkBlocks adds a BR
after the translation node.
This caused the ancestor [data-oe-model] to be set as o_dirty, event if
it was not editable or [contenteditable].
On save, the ancestor with .o_dirty[data-oe-model] was saved while
containing translation branding SPAN, which when editing the page in
source language, would cause an error on save.
Fix:
Up to 19.0, when the website editor is started in non-translation mode:
remove the translation branding SPAN.
[1] d4d428ff1d5be46135973aa806f206a1076bfcf7
[2] f09dc4d9d35e1e3707c9483fc6004cf162a3f4ca
opw-5234578This update fixes an issue where credit notes generated in Spain (l10n_es_edi_facturae) were failing validation by the FACe tax authority due to incorrect XML formatting. The fix ensures the required Spanish reason codes are used, improving compliance with Spanish tax regulations. Additionally, the reversal wizard has been streamlined for clarity.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving user experience.
Original PR description
In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939
This update fixes a bug where users could return more products than were initially picked up in rental orders. Previously, the system didn't prevent exceeding the pickup quantity during returns, leading to inaccurate inventory counts. This change ensures returns cannot exceed the original pickup quantity, maintaining accurate rental records.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015
This update ensures that the status of a sale order is correctly updated to 'Sales Order' in the Sales module after a payment is processed through the Point of Sale (PoS) system. Previously, the system didn't update the order status, leading to inconsistencies. This fix resolves a bug that prevented accurate order tracking after PoS transactions.
Original PR description
**Steps to reproduce:** - Make a quotation in the Sales module - Go to PoS, click Quotation/Order and select your quotation - Select Settle the order - Go through with the payment - Go back to the…
**Steps to reproduce:** - Make a quotation in the Sales module - Go to PoS, click Quotation/Order and select your quotation - Select Settle the order - Go through with the payment - Go back to the Quotation in the Sales module The Status widget still shows Quotation instead of Sales Order **Why the fix:** Since 18.3, the sale_order.state was not updated anymore when the state changed through the PoS. This happened because we would only change the sale_order state if there was a downpayment involved. In 18.2, we always recomputed the sale_order that was linked to the order we are currently settling. The way it is done now is part of the same way it was done in 18.2 and before, meaning we add the linked sale_order regardless of downpayments. In 18.2, we did an action_confirm on the selected sale_orders, but doing that in 18.3 will create another picking for this sale_order. This is not what we want as the picking is now handled and created by the PoS. This fix will just put the related sale orders in the "sale" state, so that users can no longer confirm it in the sales modules, which would create a second picking and create duplicates. opw-5033979 Forward-Port-Of: odoo/odoo#226008
This update resolves an issue where corrupted translation files for the l10n_id_efaktur_coretax module were preventing proper translations. The files have been regenerated to ensure accurate and consistent translations are available. This ensures the application functions correctly with Indonesian language support.
Original PR description
Two forward-port commits[^1],[^2] corrupted the POT files of these modules. They both resulted in missing `msgstr` entries causing the `msgmerge` in Weblate to fail. This commit regenerates the POT files to fix the issue. [^1]: https://github.com/odoo/odoo/commit/4e51a4a259bbb36dbbd7f6aa59ba30280f97cd89 [^2]: https://github.com/odoo/odoo/commit/f3286d792e17746d2330b5e06d5c5c8e01c52928 Forward-Port-Of: odoo/odoo#237308 Forward-Port-Of: odoo/odoo#237031
12 changes
Resolved issues and error corrections
This update fixes an issue where deprecated accounts (inactive accounts) were not appearing in the General Ledger report. The change adjusts how Odoo filters account data, ensuring historical accounts with transactions are correctly displayed in reports. This improves the accuracy of financial reporting.
Original PR description
**Description:** Deprecated accounts (active=False) with historical transactions were not appearing in the General Ledger report. **Steps to Reproduce**: - Go to Accounting > Reporting > General…
**Description:** Deprecated accounts (active=False) with historical transactions were not appearing in the General Ledger report. **Steps to Reproduce**: - Go to Accounting > Reporting > General Ledger - Choose an account code from the report (e.g 121000) - Go to Configuration > Chart of Accounts - Click on the account code 121000 and set the active field to False - Go back to the General Ledger report and notice the account cod no longer exist in the report even though it historical transactions **Root Cause:** In Odoo 18.3, the `deprecated` field was replaced with the `active` field. - `deprecated` field: Manual filtering only (where explicitly coded) - `active` field: Automatic ORM filtering (implicit in ALL searches) When the account search in `_query_values()` executes, Odoo's ORM automatically adds `AND active = TRUE` to filter out inactive records. This means deprecated accounts are silently excluded from reports. **Fix:** Added `with_context(active_test=False)` to the account search which disables automatic filtering for this specific query, restoring the original behavior where deprecated accounts appear in historical reports while remaining hidden in form dropdowns. opw-5092275
This update fixes an issue where channel names in the sidebar weren't displaying correctly when inviting users to channels. The change ensures the correct channel name is used in the invite dialog, improving the user experience and preventing confusion. This resolves a visual inconsistency.
Original PR description
Before this commit, certain channels whose names were computed on the client side did not appear correctly as the title of the invite dialog when opened via the sidebar actions. This commit resolves the issue by using the channel’s displayName instead of the thread.name to ensure the correct title is shown in the invite dialog. task-5357104
This update resolves a problem where invoices weren't being reconciled correctly when statement lines matched invoice installments. The fix ensures that reconciliation stops when a statement line is fully paid, preventing incorrect suspense account creation and improving invoice reconciliation accuracy.
Original PR description
When reconciling an invoice with a statement line from the invoice widget, we want to stop the reconciliation whenever the amount of the statement line is depleted, creating a partial if needed. A previous fix was doing just that, but forgot about the case of a statement line having exactly the same amount as one of the invoice installments. As no partial was created (since the total amount of the installment was paid by the statement), the loop going through the invoice installments would not break, and the reconciliation would then add a suspense account line after adding all the invoice installments.
This update fixes an issue where the initial message subtitle wasn't displayed correctly for group chats in Odoo. The change ensures the correct start message and subtitle are shown across all channel types, improving the user experience. A new test has been added to verify this functionality.
Original PR description
Before this commit, The start message subtitle condition was incorrect for group chats, this commit corrects that condition and also add a test to cover all the channel types to show correct start message and subtitle. Before: <img width="625" height="109" alt="image" src="https://github.com/user-attachments/assets/830f9574-573f-4448-b54f-b70c8a4685ef" /> After: <img width="640" height="133" alt="image" src="https://github.com/user-attachments/assets/bcba270a-88fc-446d-9015-1125872c5748" />
This update addresses a missing feature in the annual corporate tax return reporting within Odoo Enterprise. The fix adds a 'reviewed bubble' and a 'Mark as completed' button to the reporting interface, streamlining the process for users to finalize and track their tax returns. This improves the usability and accuracy of tax reporting.
Original PR description
Missing: - reviewed bubble - Mark as completed button
This update resolves an issue where corrupted translation files for the l10n_id_efaktur_coretax module were preventing proper translations. The team regenerated the files, ensuring accurate translations are available for Indonesian users. This ensures consistent and correct functionality for our Indonesian customers.
Original PR description
Two forward-port commits[^1],[^2] corrupted the POT files of these modules. They both resulted in missing `msgstr` entries causing the `msgmerge` in Weblate to fail. This commit regenerates the POT files to fix the issue. [^1]: https://github.com/odoo/odoo/commit/4e51a4a259bbb36dbbd7f6aa59ba30280f97cd89 [^2]: https://github.com/odoo/odoo/commit/f3286d792e17746d2330b5e06d5c5c8e01c52928 Forward-Port-Of: odoo/odoo#237073 Forward-Port-Of: odoo/odoo#237031
This update optimizes the Odoo stock module by preventing unnecessary processing when unpacking empty product packages. Previously, a slow function was executed regardless, impacting user request speeds. Now, the system only performs these tasks when actual products are present, leading to a faster and more responsive experience.
Original PR description
For an empty package the `quant_tasks` function will be executed without restriction of scope and can potentially slow the user request intensly. And if there is no quants in the package the tasks are not necessary. After the unpacking of the quants they are not in the package anymore. Causing the call to quant_tasks to be done on an empty recordset. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234370
This update streamlines our logging of WebSocket messages to reduce excessive data and improve readability. Previously, full message logs were overwhelming with large base64 encoded data. Now, we log only the message type and device at 'info' level, providing clearer and more manageable logs.
Original PR description
Before this commit, we logged the full websocket messages received at 'debug' level, and the action device at 'info' level. Logging the whole message causes the logs to be flooded with large base64 print data. After this commit, log the message type and device both at 'info' level. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237123 Forward-Port-Of: odoo/odoo#236651
This update corrects a minor error in the Finnish language translations for the Enterprise reporting module. Specifically, the correct language tag (@fi) was added to ensure accurate translation of report names. This ensures that reports are displayed correctly for Finnish-speaking users.
Original PR description
In this commit [[1]], we wrongly set the name for the translation in Finnish. Indeed, we should add @fi at the end to make sure it's translated properly. This commit adds the `@fi` when necessary. no task id [1]: https://github.com/odoo/enterprise/commit/4ae3c4d2bdb0ef05ffb53930b31f2bf15fd422ee Forward-Port-Of: odoo/enterprise#100304
This update fixes an issue where credit notes weren't correctly validated by the Spanish tax authority (FACe). The fix ensures the XML data used for credit notes adheres to Spanish regulations, resolving a potential compliance problem. Additionally, the reversal wizard has been streamlined for clarity.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving user experience.
Original PR description
In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939
This update fixes a bug where users could return more products than they had picked up in rental orders. Previously, the system didn't prevent exceeding the pickup quantity during returns, leading to inaccurate inventory counts. This change ensures returns cannot exceed the initial pickup quantity, maintaining accurate rental records.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015
2 changes
Resolved issues and error corrections
This update ensures kiosks only utilize payment methods explicitly configured for that device. Previously, kiosks would incorrectly prompt for unavailable payment options, leading to a poor user experience. This fix prevents errors and improves the kiosk's functionality by restricting payment method selection.
Original PR description
Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/odoo/pull/217467
This update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving user experience.
Original PR description
In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939
8 changes
Resolved issues and error corrections
This update resolves a technical error preventing access to enrollment date information within the Odoo Enterprise system. The change adds necessary groups to correctly identify and retrieve this data, ensuring accurate reporting and payroll processing for users in the UAE. This fix improves data reliability and functionality.
Original PR description
add the groups for the version field runbot-error: 234072
This update ensures that the Annual Corporate Tax Return accurately reflects custom fiscal year periods. Previously, the system incorrectly identified the fiscal year, leading to inaccurate closing dates. This fix now correctly uses the defined fiscal year start and end dates for tax return reporting.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432 Forward-Port-Of: odoo/enterprise#100254 Forward-Port-Of: odoo/enterprise#100034
This update fixes an issue where users without administrative access were encountering access errors when creating projects based on templates with field service. The fix involves adding a necessary security check to ensure proper access rights are enforced, preventing errors and allowing project creation for authorized users.
Original PR description
--- ## Short functional explanation of the error Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign…
---
## Short functional explanation of the error
Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign an employee, their schedule will be retrieved to see if it matches the start and end date of the project.
If we try to create a project based on this template as an employee who's not an admin (only has rights for the project and services apps, for example), this will result in the error
This operation is allowed for the following groups:
- Employees/Administrator
- Employees/Officer: Manage all employees
Contact your administrator to request access if necessary.
Explanation: as we try to retrieve the employee schedule with an employee who doesn't have access rights to the Employee infos, it raises an access error.
## Reproduction Steps
1. As an admin, go to Projects and create a new project with a new stage and a new task. Assign an employee to this task.
2. Enable debug mode and go to the settings of the project. Under field service, check Field Service, then save.
3. Click on the small cog next to the project name and click Convert to Template.
4. Set a planned start and end date for the project and for its task. Assign a customer on the task.
5. Go to Users and select a different user than the one you assigned to the task.
6. Set this user administrator for Project and Field Service.
7. Make sure that this user also has an employee profile. Log in with this user and create a project based on this
### Expected behavior
The project is created without the entries the employee doesn't have access to
### Unexpected behavior
An access error is raised
## Origin of the issue
A sudo() was missing in the code.
__
opw-5263024
Forward-Port-Of: odoo/enterprise#100055This update corrects a critical error in how payroll versions are determined, which previously led to inaccurate pay calculations. By removing a flawed default date calculation, the system now correctly identifies payroll versions, ensuring accurate payments for employees. This resolves a potential issue impacting payroll accuracy across multiple countries.
Original PR description
Current version_id computation does not depend on payslip dates, which could very often lead to wrong calculations, in this PR we solve this by removing the cyclic dependency between dates and version compute by removing the default computation of the date_start, which is often wrong anyway in the case of a single manual payslip Forward-Port-Of: odoo/enterprise#99722 Forward-Port-Of: odoo/enterprise#95257
This update corrects a problem where payslip dates were incorrectly linked to the salary configuration month, leading to inaccurate tax calculations (ATN). The change ensures payslip dates align with the actual contract dates, guaranteeing correct ATN application. This improves payroll accuracy and compliance.
Original PR description
The payslip date is in the current month of when the salary configurator is used which may be different from the date on the version. That would lead to have the payslip outside of the contracts date and not take the ATN into account. Forward-Port-Of: odoo/enterprise#99909
This update fixes an issue where new contract versions created through the configurator would lose the employee's work address and location. The change ensures that this critical information is consistently saved, improving data accuracy and streamlining contract management processes. This update primarily impacts the HR contract management module.
Original PR description
When a new version is created by the configurator, we need to keep the work address and location. Forward-Port-Of: odoo/enterprise#100344
This update resolves an issue where using the 'force capture' feature in Stripe payments could lead to the creation of duplicate expense records. The fix ensures that only one expense is generated per transaction, improving data accuracy and reducing potential accounting errors. This primarily impacts users utilizing the Stripe expense capture functionality.
Original PR description
It's possible for multiples expenses to be created when using force capture. - Setup a company in EU and do the account onboarding - create a card - simulate a test purchase with force capture - after the webhook event issuing_transaction.* is received, an expense should have been created - now send again this event to the server (from the stripe dashboard or any other way) - a second expense will be created with the same transaction_id Forward-Port-Of: odoo/enterprise#99647
This update fixes a potential issue where rental orders could incorrectly record more returned products than were actually picked up. The change ensures that returned quantities never exceed the initially picked-up quantity, improving the accuracy of rental order tracking and reducing potential discrepancies. This impacts the rental process and reporting.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015
23 changes
Resolved issues and error corrections
This update resolves an error that occurred when users tried to replace work entries within a payslip using the Gantt view. The issue stemmed from incorrect data being passed to the view, causing 'Missing record' or 'Contract out of range' errors. This fix ensures the correct employee ID is used, improving the reliability of the work entry scheduling process.
Original PR description
**Steps to reproduce:** - Install the hr_payroll module. - Open the form view of an employee with a running contract and click on the Payslip smart button. - Create or open an existing payslip, then open the Work Entries from smart button. - Click on any day cell and then click the Quick Replace button. **Issue:** Clicking the Quick Replace button (next to Set) triggers an error, 'Missing record' or 'Contract out of range.' **Cause:** The issue occurs due to an incorrect context being passed in the Gantt view (https://github.com/odoo/odoo/pull/223409). The view incorrectly passes the payslip ID instead of the employee ID. **Fix:** This PR updates the context to ensure the correct employee ID is passed to the Gantt view. task-5219487
This update corrects a minor issue where Odoo would display an error if a required field was hidden. The change ensures that Odoo correctly handles invisible fields, preventing unexpected errors and improving user experience. This ensures data entry processes run smoothly.
Original PR description
When a required select is invisible, you may get an error saying the a required field is not set. So like for other type of fields, we check the visibility of the field.
This update corrects a bug in how purchase orders with warnings are displayed. Previously, POs without any activities were shown, regardless of whether a warning was present. This change ensures that POs with warnings are correctly identified and displayed, restoring the expected behavior from previous versions.
Original PR description
Steps To Reproduce ------------------ 1- To purchase orders 2- Create random purchase orders (with activity and without and with warning) 3- Select the Warning Filter Issue ----- 1- Only POs with no…
Steps To Reproduce
------------------
1- To purchase orders
2- Create random purchase orders (with activity and without and with warning)
3- Select the Warning Filter
Issue
-----
1- Only POs with no activities show on the list.
2- The behavior in versions previous to 18.3 works perfectly fine, showing only POs with warnings.
Cause
-----
The issue is caused by this commit: 92301a5b300dec1ddfca44dc35318b83d67c56fa.
The search logic for the activity_exception_decoration field was changed to refuse negative operators (`!=`):
https://github.com/odoo/odoo/blob/92301a5b300dec1ddfca44dc35318b83d67c56fa/addons/mail/models/mail_activity_mixin.py#L118-L121
This forces the ORM to invert the filter:
https://github.com/odoo/odoo/blob/9a8350cb476af73d6bf4eea75344963eac1c7831/odoo/orm/domains.py#L873-L880
For this case, this transforms the intended query:
`Exists(activity_exception_decoration != False)` ("Has Warning")
Into the inverted query:
`NOT Exists(activity_exception_decoration == False)` ("Does NOT have a Normal activity")
This incorrectly hides records that have both warning and normal activities, and incorrectly shows records with no activities at all.
opw-5177277
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236732This update resolves an issue where timesheet entries linked to reversed invoices were previously uneditable. Now, after reversing an invoice, users can correctly modify timesheet entries associated with that invoice through the recorded hours feature, ensuring accurate time tracking and reporting. This improves the reliability of financial data.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#236601 Forward-Port-Of: odoo/odoo#201921
This update fixes an issue where tax return amounts were incorrectly calculated for section reports, specifically in the LU tax return. The change ensures the correct return periodicity is used by retrieving the return type from the section source, resolving a discrepancy between the main report and the section report.
Original PR description
We have some reports with sections, like l10n_lu generic tax return.
Since account.return are born, when submitting the lu tax return, the periodicity is wrongly
computed, because of the self in `_init_options_return_periodicity` is the section report, not the main,
but the account.return.type is set with report_id = main report
Step to reproduce:
With a LU company:
1. Create a journal entry for a previous period
2. Submit the tax return for the same period
3. The amount shown is the amount of the current month
Solution: use options['sections_source_id'] to fetch the return_type instead of self.return_type_ids
opw-5163352
Forward-Port-Of: odoo/enterprise#100063This update fixes an issue where the price displayed in Point of Sale (PoS) was incorrect when using non-groupable units of measure. The fix ensures that the correct price unit is applied during order settlement, leading to accurate pricing calculations for products with these specific UoMs. This improves the reliability of PoS transactions.
Original PR description
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If…
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g) to the original product UoM (kg), and we update the quantity accordingly (in this example by dividing by 1000). https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96 So this step updates both the qty and the unit_price. https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161 However, when the UoM is not groupable, we split the lines by taking into consideration the updated qty, but we still use the old price_unit, which creates an inconsitency and wrong calculations. The fix ------- When splitting the lines, we're just supposed to change the qty per line to max 1, but we're not supposed to change the price per unit for this qty. We now use the updated `price_unit` to have a correct math. opw-5232571 Forward-Port-Of: odoo/odoo#237246 Forward-Port-Of: odoo/odoo#236008
This update resolves an issue where archived loyalty cards were still accessible and usable within the system. The fix corrects a filtering error that prevented inactive cards from appearing in search results. Additionally, it prevents points from being incorrectly applied to archived loyalty cards, ensuring accurate reward management.
Original PR description
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a…
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2: In this bug, earned points on archived loyalty can be used to claim rewards. #### To reproduce: 1- Install `Sale` and `Ecommerce` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Add a rule to grant 10 points per order 5- Apply a reward in exchange of 10 points 6- Create a `Loyalty Card` for the admin with 0 points. 7- In Ecommerce, add a product to your cart 8- Remove the product from the cart 9- Archive the loyalty card created for the admin 10- In Ecommerce, add another product to cart 11- As you see, you still can use the loyalty card ### Cause: When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards. To prevent this, we can unlink points from draft sale order when the card is archived. opw-5166696 Forward-Port-Of: odoo/odoo#233645
This update resolves a bug that prevented users from correctly sorting the Time Off Ledger report. The issue stemmed from a default sorting rule that conflicted with user-specified sorting directions. Now, users can reliably sort the report in both ascending and descending order, ensuring accurate reporting.
Original PR description
Version - 19.0 ## Issue: Sorting the Date column in the Time Off Ledger triggers a traceback when attempting to sort in ascending order. ## Steps to reproduce: - Open the Attendances app - Navigate…
Version - 19.0 ## Issue: Sorting the Date column in the Time Off Ledger triggers a traceback when attempting to sort in ascending order. ## Steps to reproduce: - Open the Attendances app - Navigate to Time Off Ledger report - Click on dates column for sorting --> you get a traceback ## Cause: The code always appends `' desc'` to the order clause to enforce a default descending sort. When the UI already provides a direction (e.g. `date:month ASC`), this results in an invalid combined order such as `date:month ASC desc`, raising: `ValueError: Invalid order 'date: month ASC desc' for _read_group().` ## Fix: Add a check to avoid appending `' desc'` when the order string already contains `asc` or `desc`. ## Impact: Sorting the Date column no longer crashes. Users can now sort the report correctly in both ascending and descending order, with descending remaining the default. task-5331052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures product prices displayed in the self-order POS accurately reflect the prices calculated using the active pricelist. Previously, prices were inconsistent, but now the system automatically applies the correct pricelist, even when presets are used without a specific pricelist assigned.
Original PR description
### before this commit: - Product cards displayed the product’s sale price instead of the price computed from the applied pricelist, even though the order total reflected the correct discounted amount. - When a preset was enabled, the pricelist was applied only if it is explicitly set on the preset. ### after this commit: - Product cards now show prices according to the active pricelist rules. - When the preset is enabled without a pricelist, the default POS pricelist is applied automatically. task-5236959
This update fixes a missing translation file for the Finnish reports module. It also removes translation from a specific sales report, ensuring consistent and accurate reporting in Finnish. This improves the usability of Odoo Enterprise for Finnish-speaking users.
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate report column names in the PO files as we have official translation for it. This commit also disables the translation on the TXT EC sales report. no task id [1]: https://github.com/odoo/enterprise/commit/4887ed53d3a22fdcd766ab0ae77da7cb0498e5a3 Forward-Port-Of: odoo/enterprise#100308 Forward-Port-Of: odoo/enterprise#99887
This update addresses a memory issue that occurred during the v19 upgrade mock crawl when retrieving product information. The fix utilizes a controlled lookup instead of a large relational prefetch, preventing the 'MemoryError' and ensuring smoother operation. This resolves a potential crash and improves stability.
Original PR description
During v19 upgrade mock crawl, accessing `source.move_ids.product_id` triggered a huge relational prefetch, crashing with: ```py File…
During v19 upgrade mock crawl, accessing `source.move_ids.product_id` triggered a huge relational prefetch, crashing with:
```py
File "/home/odoo/src/odoo/19.0/addons/delivery/models/delivery_carrier.py", line 209, in _match_must_have_tags
products = source.move_ids.product_id
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_relational.py", line 75, in __get__
super().__get__(remaining, owner)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1692, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1599, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
Full traceback: https://pad.odoo.com/p/aTIGHsnDMrfMENfmU5TK
Use a controlled lookup instead.
opw-5223443
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving usability.
Original PR description
In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939
This update addresses a technical issue identified by Odoo's automated testing system (runbot). The fix ensures that localization tours within the Point of Sale module function correctly for different regions, improving the user experience for international customers. This resolves a previous bug that prevented proper localization setup.
Original PR description
Fix runbot issue runbot-233183 Forward-Port-Of: odoo/enterprise#100069 Forward-Port-Of: odoo/enterprise#99370
This update resolves issues with how the Hoot mock server handles 'blob:' URLs and nested data streams within unit tests. It now correctly mocks these URLs and properly parses data, ensuring more reliable test results and improved functionality for attachments.
Original PR description
See commit messages for details --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236395 Forward-Port-Of: odoo/odoo#234558
This update corrects a missed step in the Finnish translation process, ensuring the POT file is properly maintained. It also translates a key business term, improving the accuracy and usability of the Odoo application for Finnish users. This ensures compliance with local regulations and a better user experience.
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate the Business ID term for the correct one. no task id [1]: https://github.com/odoo/odoo/commit/7ef02a48f3c93cb8aca9337a27c3c87636fb03a0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237098 Forward-Port-Of: odoo/odoo#236469
This update fixes an issue where users were incorrectly changing product details on combo item lines. To address abuse of the system, a temporary workaround has been implemented requiring users to hide product fields before editing the description. This ensures data integrity within combo orders.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes). Forward-Port-Of: odoo/odoo#237148 Forward-Port-Of: odoo/odoo#235547
This update resolves an instability issue within the Point of Sale (PoS) localization tour. The change removes a problematic closure step, which previously caused frequent failures due to the PoS's complex setup. This improves tour performance and reliability.
Original PR description
backport of : https://github.com/odoo/odoo/pull/231884 Remove the closing of the PoS in the tour as it is really unstable and fail a lot. It's mostly due to the fact that the PoS take a long time to close with a lost of modules installed. This will also make the tour faster. runbot-233183 Forward-Port-Of: odoo/odoo#236747 Forward-Port-Of: odoo/odoo#234310
This update resolves an issue where the base_import module would fail when users lacked access to the underlying data definition. The fix now includes checks for field group restrictions, preventing crashes and ensuring smoother data import processes. A new test case has been added to verify this improved behavior.
Original PR description
…ible https://github.com/odoo/odoo/pull/236037 ignores the properties field if we don't have access to the definition model at all. However, we should also check field groups to avoid crashing if the user cannot access the definition field because of group restrictions. Forward-Port-Of: odoo/odoo#237166 Forward-Port-Of: odoo/odoo#236912
This update resolves a bug where setting the background image width to 0px in the website builder's 'Repeat pattern' mode caused the background to disappear. The fix ensures that the input fields reset correctly to the default 'auto' size, maintaining proper background image display.
Original PR description
__Current behavior before commit:__ In "Repeat pattern" mode, users can set the background image's width and height to 0px, which doesn't make sense. Additionally, clearing these input fields resets their values to 0px instead of reverting them to `auto`. __Description of the fix:__ Make it possible to clear those fields by setting their default value to `null` and set the minimum value to 1 to prevent the image from disappearing. __Steps to reproduce:__ 1. On the website, drop a `s_cover` snippet 2. Set Background > Image > Position to "Repeat pattern" 3. Delete the content of the "Width" input => The background disappears. task-5094899 Forward-Port-Of: odoo/odoo#231216
This update resolves a problem where credit notes weren't correctly validated by the Spanish tax authority (FACe). The fix ensures the XML data used for credit notes adheres to Spanish regulations, improving compliance. Additionally, the reversal wizard has been streamlined for better usability.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update resolves an issue that prevented fiscal receipts from generating correctly when multiple payment methods were used in a POS order. The fix ensures unique identification of payment methods, eliminating a 'duplicate key' error that was causing failures.
Original PR description
When multiple payment methods are used in a POS order, the fiscal receipt generation fails with "Got duplicate key in t-foreach: 0" error. This occurs because all payment methods have the same default it_payment_index value (1), causing duplicate keys in the Owl template's t-foreach loop. This fix uses the payment's database ID (payment.id) as the unique key in the template loop instead of relying on the payment method's it_payment_index value.
This update ensures return deadlines are accurately calculated across all Odoo databases, particularly those migrated before a previous upgrade. It resolves an issue where returns marked as 'completed' without a deadline date would cause errors, now defaulting them to a deadline of today to maintain data consistency.
Original PR description
[FIX] account_reports: returns: recomputed date_deadline when is_completed is set to False To align it with the current deadline delay configured on the return type, and keep data consistent. Also,…
[FIX] account_reports: returns: recomputed date_deadline when is_completed is set to False To align it with the current deadline delay configured on the return type, and keep data consistent. Also, databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed with no value set for the deadline. With this, we ensure unmarking them as completed will grant them one. opw-5259168 ==================================================================== [FIX] account_reports: returns: avoid error when computing days_to_deadline for migrated dbs Databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed, but without any date_deadline. On such a db, if you open the list of returns, then remove the "to do" filter, you get an error, because _compute_days_to_deadline tries to substract today from None. This commit just makes the computation more resilient, and arbitrarily chooses that a return without deadline is due today. opw-5259168
This update fixes a potential issue where rental returns could exceed the quantity picked up. Previously, users could return more products than were initially taken, leading to inaccurate inventory counts. This change ensures that returned quantities never exceed the picked-up quantities, improving rental accuracy and reporting.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015
8 changes
Resolved issues and error corrections
This update resolves an issue where the account no followup feature wasn't consistently working correctly. The fix involves optimizing the search process for better accuracy and reliability, ensuring data is processed properly before searching. This improves the overall functionality of the account no followup module.
Original PR description
- unwrap Markup before applying regex substitution - word-bound search term
This update resolves an issue where document previews were not updating correctly after renaming documents. Previously, the preview displayed the old attachment name even after a successful rename. This change ensures that document previews always reflect the most current document name, improving data consistency and user experience.
Original PR description
BUG 1: --------- **steps to reproduce**: 1. Install documents 2. Open any document 3. Go to Action > Rename 4. Rename the document 5. Preview it and read the name showed there **issue**: When…
BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there
**issue**:
When previewing the document, it still shows the old attachment name.
**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:
1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130
2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383
**solution**:
Use the document name when previewing it
BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.
**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.
**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.
Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.
**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.
**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
<summary>Click here to see the results:</summary>
Before:
<img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
After:
<img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>
</details>
opw-5065433This update fixes an issue where vendor bill payment statuses remained incorrect after deleting or resetting payments. The change ensures that the bill's status accurately reflects the payment's state, resolving a discrepancy observed compared to customer invoices. This improves data consistency and reporting accuracy.
Original PR description
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment…
Steps to reproduce: ------------------------- 1. Install the Accounting module. 2. Create and confirm a Vendor Bill. 3. Click on Pay and create a payment for the bill. 4. Open the created payment using the smart button. 5. Delete the payment or click on Reset to Draft. Observation: ------------------------- 1. On deleting the payment: The Vendor Bill still shows the "In Payment" status even after the payment is deleted. 2. On resetting the payment to draft: The Vendor Bill also remains in the "In Payment" status instead of reverting to "Not Paid". This behavior is not observed for customer invoices, where the payment state updates correctly in both cases. Issue: ------------------------- 1. Delete case: In the `unlink` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_payment.py#L938-L945 the `linked_invoices` variable only includes invoices that are reconciled (i.e., their journal items are matched). Since the Vendor Bill is not yet reconciled, it is excluded from recomputation. Hence, its `payment_state` remains unchanged. 2. Reset to draft case: In the `_compute_payment_state` method, https://github.com/odoo/odoo/blob/b991f766e28dc71f8627fdfbf2d59589d9707d3a/addons/account/models/account_move.py#L1162-L1163 the compute depends on the state of reconciled payments. However, since these payments are not reconciled, the compute method is not triggered, and the payment state remains outdated. Solution: ------------------------- Added `matched_payment_ids.state` in the depends of the `_compute_reconciled_payment_ids` method to ensure it recomputes correctly when payment state changes on setting payment to draft or deleting payment Ticket [link](https://www.odoo.com/odoo/project.task/5208772) opw-5208772
This update resolves an issue where adding content to the website header caused unexpected scrolling behavior. The fix removed a problematic variable that wasn't consistently updating, leading to a jumpy scroll. This ensures a smoother and more reliable user experience when adding or modifying content on the website.
Original PR description
Before this commit, the header height was stored in a global variable. This variable wasn't always updated, which led to issues regarding the scroll. When adding elements in the header that increased its height, the scroll would jump and showing / hiding the header. This commit removes the need of the headerHeight variable. Steps to reproduce the bug: - Add a "Text Highlight" inner content above the ContactUs button - Add multiple Title snippets below one another (When adding the third one, the page scroll indefinitely) (The number of snippets to drop may vary depending on the viewport) task-4267249 Forward-Port-Of: odoo/odoo#185812
This update fixes a translation error in the Netherlands (l10n_nl) module. The description for the 9% ST tax was previously incorrectly translated as 'TVA' (VAT). This change ensures accurate reporting and compliance with Dutch tax regulations, improving the accuracy of financial data.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#236655
This update fixes an error in the Peru tax report (RVIE Sales 14.4) export that incorrectly included credit note amounts in the report. The fix ensures the report accurately reflects SUNAT regulations for credit note reporting, improving compliance and data accuracy for Peruvian businesses.
Original PR description
How to reproduce the issue: -With l10n_pe localization - Create an invoice for the previous period, generate a credit note for that invoice in the current period. - In the tax return with report VAT Report (RVIE Sales 14.4) (PE), download the txt file. - Columns 15(base_igv), 16(amount_discount), 17(tax_igv) and 18(tax_igv_discount) are wrong: the credit note is included in col 15 and 17 However, according to SUNAT spec the rule should be: - If the NC modifies a document issued in the same period: amounts must be reported in Col. 15 and 17 (with the negative sign already inherent in the NC). - If the NC modifies a document issued in previous periods: amounts must be reported in Col. 16 (Discount BI) and Col. 18 (Discount IGV/IPM) (values must be negative), and not in 15/17 opw-5094466
This update resolves an issue where invoices using specific document types within the l10n_ar localization pack couldn't be printed correctly. The fix ensures that the invoice template supports multiple Spanish languages, allowing printing regardless of whether es_AR is installed. This improves usability for customers using the Arabic localization.
Original PR description
#The issue: - With l10n_ar company - Make sure that the language es_AR is not installed. - Create an invoice where the Document type (l10n_latam_document_type_id) code is in 201, 202, 203, 206, 207, 208, 211, 212 or 213 - Try to print the invoice, the following error occurs: odoo.addons.base.models.ir_qweb.QWebException: Error while render the template UserError: Invalid language code: es_AR In the report_invoice template used in l10n_ar, if the document type is 201, 202, 203, 206, 207, 208, 211, 212, or 213, the amount in letters is mandatory. Currently, the template is hard-coded to use es_AR. As a result, if the customer does not have the es_AR language installed, the invoice cannot be printed, even if another Spanish language is available. opw-5079885 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where changes to the 'analytic.project_plan' system parameter didn't properly update related fields in the analytic accounting system. Now, when this parameter is modified, the system dynamically adjusts the associated fields on analytic lines, ensuring data consistency. This prevents errors and ensures accurate reporting.
Original PR description
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan`…
A field on `account.analytic.line` is created for every plan using the `id` of the plan to make the names unique, like `x_plan{id}_id`. The plan that has the ID of the `analytic.project_plan` parameter does not get a dynamic field, it uses `account_id`. If you change the system parameter for analytic.project_plan, the plan with the corresponding value will now use `account_id,` and the plan that corresponds to the previous default value will have no corresponding field on `account.analytic.line`.
So, when the project plan system parameter changes, the dynamic fields that are created for each analytic plan (apart from the project one) do not get updated.
Steps:
1. Set the `analytic.project_plan` system parameter to a value other than `1`
2. Enable `Analytic Accounting` setting under `Accounting > Analytic`
3. Create a sales order with a service product that creates a project.
4. Confirm sales order
5. Traceback: `ValueError: Invalid field account.analytic.line.x_plan1_id in leaf 'x_plan1_id', 'in', [23])`
We now extend the write method on `ir.config_parameter` so that when the value of the analytic.project_plan is changed the dynamic fields on `account.analytic.line` are properly added and removed. This solution always creates a field for the previous value and deletes a field for the new value so that no plan ever has two fields referencing it.
Ticket [link](https://www.odoo.com/odoo/project.task/5069381)
opw-5069381
Forward-Port-Of: odoo/odoo#2319811 change
Resolved issues and error corrections
This update fixes a minor issue where the 'Copy' button in the Payment Link wizard incorrectly displayed. The change ensures the button clearly states 'Generate a Payment Link', improving user clarity and reducing potential confusion when creating payment links for sales orders. This improves the user experience.
Original PR description
Steps to reproduce: 1. Install sale_management 2. Create a sale order and confirm it 3. Open the Generate a Payment Link wizard from the cog menu Issue: The button in the wizard displays “Copy” instead of “Generate a Payment Link”. Cause: The custom paymentWizardCopyClipboardButtonField widget did not forward the field’s string to its component props, causing the default "Copy" label to be used. Solution: Forward the string prop in the widget’s extractProps implementation. opw-5224112