Wednesday, November 26, 2025
21 changes · 19.0
Enhancements to existing features
This update enhances Odoo's support for Argentina's tax regulations by adding necessary tax accounts and definitions. This ensures businesses using the l10n_ar module comply with local laws and accurately report their taxes, minimizing accounting errors.
Original PR description
Description of the issue/feature this PR addresses: On the AFIP portal, there are specific tax values and scenarios when registering purchase invoices that are not currently supported by the l10n_ar…
Description of the issue/feature this PR addresses: On the AFIP portal, there are specific tax values and scenarios when registering purchase invoices that are not currently supported by the l10n_ar module. Desired behavior after PR is merged: This improvement adds the required tax accounts and definitions for Argentina localization. It ensures legal compliance and proper fiscal reporting for companies using l10n_ar. Key changes: Added new tax account templates for various Argentine tax scenarios, including “Otros Impuestos” and “Impuestos Internos”. Updated and extended tax definitions to align with AFIP and ARCA requirements. Improved mapping between tax codes and accounts for accurate reporting. These changes make it easier for users to configure and use Odoo with accurate fiscal settings for Argentina, reducing the risk of accounting errors and improving compliance with local regulations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the product and payment screens by removing the left-side cart and simplifying the guest count setting on the payment screen. These changes enhance the user experience and improve the visual clarity of key sales processes. The update also includes minor UI refinements for category selection and time slot presets.
Original PR description
After this commit, the cart on the left side of the product screen is removed. - Category cards have now border when selected. - The VAT summary on the product with attributes is now removed. - On the payment screen, there is now a small light grey button under the price summary to set the number of guests at any moment. - Small change on the preset time slot button. Task : 5145441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that all admin users in Odoo have access to the full suite of accounting features. Previously, access was limited, which created a restriction on administrative capabilities. This change improves administrative efficiency and consistency.
Original PR description
CMON it is the **** admin not just Marc Demo
This update enhances the bank reconciliation process by providing a clearer display of transaction details and statement line information. It also introduces features like a cooldown for chat messages and allows users to expand payment references for full visibility, streamlining the reconciliation workflow.
Original PR description
See commits' description
Resolved issues and error corrections
The Gantt view in the Project app was incorrectly calculating unavailable time when flexible working hours were enabled. This update resolves a bug where the view randomly grayed out days, now ensuring accurate representation of employee availability. This improves the usability of the project scheduling feature.
Original PR description
To reproduce: ============= 1. Activate flexible working hours on the company calendar 2. Go to Project app -> all tasks 3. Switch to Gantt view notice that on the unassigned tasks row, two days are grayed out randomly Problem: ======== When flexible working hours is activated, the unavailability intervals are computed with an estimation: we take the total of working hours per week and we divide it by number of hours per day to get `N` days, so we estimate that from `now` to `now + N` days are working days, and the rest are non-working days. This is wrong because the working hours may not be evenly distributed over the week, and between today and tomorrow we get different unavailability intervals. Solution: ========= When flexible working hours is activated, we consider that all days are working days, so there is no unavailability interval to consider. opw-5257081 Forward-Port-Of: odoo/enterprise#100385
This update corrects an error preventing the system from successfully retrieving invoice documents from the Viettel e-invoice API. The issue stemmed from incorrect parameter requirements in the API documentation, which were causing a 'not found' error. This fix ensures seamless document retrieval for Vietnamese e-invoicing.
Original PR description
* Problem: When trying to get document from sinvoice, we get error not found * Reason: in the api document the parameter not include 'strIssueDate' and also the 'transactionUuid' not require at all, but if we include 'transactionUuid' we still get 400 error 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#236628
This update resolves a problem where the exchange rate was missing from invoices generated for currencies other than AED in older Odoo versions (17.0 and 18.0). The fix addresses a conflict within a shared invoice template used across multiple countries, ensuring accurate exchange rate display. This improvement impacts invoice accuracy and consistency.
Original PR description
Steps to reproduce: - install l10n_ae - switch to AE company - create an invoice with a currency != AED and print -> exchange rate shows - install l10n_sa_edi - print the invoice with the AE company -> in 17.0, the exchange rate is missing -> in 18.0, the template is broken The same fix can be applied for both 17.0 and 18.0. The main issue is that l10n_gcc_invoice is a template for 5 different countries, and all of them inherit it without primary=True, which results in many conflicts if several of these countries are installed on the database. Here, we only try to solve the most apparent issue, which is the broken template for the exchange rates. Note that in 19, a major PR has been fixing this inheriting issue: https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7 opw-5215971 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237193 Forward-Port-Of: odoo/odoo#236844
This update fixes an error in the Peru tax return (RVIE Sales 14.4) report that incorrectly included credit note amounts in the VAT columns. The change 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 Forward-Port-Of: odoo/enterprise#96146
This update prevents users from resetting invoices to draft while a Point of Sale (POS) session is active. Previously, the action would still be performed despite a warning notification. Now, an error notification is displayed, ensuring data integrity and preventing potential issues during POS transactions.
Original PR description
Before this commit, when trying to reset to draft an invoice linked to a POS order with an ongoing session, a warning notification was sent but the action was still performed. Now, the user is prevented from doing so and an error notification is sent instead. task: 5265836 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where notifications for inbox messages (like signature requests) weren't consistently displayed in the top messaging menu. Previously, users only saw these messages within the 'Discuss' app > Inbox. This change ensures that inbox messages are now correctly reflected in the main messaging menu, improving notification visibility and user experience.
Original PR description
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of…
**Steps to reproduce:** - Set handle notifications in Odoo for one user - Go to `Sign` app with another user - Create a signature request for the first user - The first user is properly notified of the signature request, as the counter badge is updated. - When clicking on the badge, no new message is shown. **Issue:** Inbox messages are not considered in the `MessagingMenu` when they are not linked to any record. It's the case when a signature request is sent and while the notification counter is updated, the message can't be seen in the top bar menu, it's only visible in the `Discuss` app > Inbox which is quite confusing for the users. In previous versions the behavior was different as the signature request was either considered as an activity or no notification was sent. Also if the inbox message is linked to a record, it only appears in the `all` filter of the menu. **Fix:** Added the inbox explicitly to the top `MessagingMenu` to be able to read the corresponding messages. We could also link the signature to its record when sending the message instead of `self.env['sign.request']._message_send_mail()` but it might cause access rights issues. Also ensured that a category `others` was used for such messages, and prevented an error caused by clicking on the conversation when the `Discuss` app was opened. Unfortunatly doing this will show duplicates in the notifications of the menu for messages which are in the inbox but which have a record set. (e.g. when such message appears, it will have one line in the inbox and one for the record itself) So we need to filter out the messages which have a thread from their record in the views to avoid it. related: https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda opw-4969005 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235234 Forward-Port-Of: odoo/odoo#228740
This update fixes a bug where only the first CFE was processed from Uruguayan vendor bills. It now handles multiple CFEs and adds unique suffixes for manual and automated document creation, improving tracking and debugging. This ensures accurate bill processing and simplifies identification of document origins.
Original PR description
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was…
1) Update l10n_uy_edi translations. 2) When an uruguayan xml file is uploaded on a purchase journal it could contain the information of more than one CFE but before this commit only the first CFE was processed. Now all the CFEs are processed. 3) Add suffix '-manual' for new vendor edi documents uuid that are created by drag and drop xml file. 4) Create xml attachment in the edi document if it is created by drag and drop xml file. 5) Add suffix '-notification' for new vendor edi documents uuid that are created by 'UY: Create vendor bills (sync from Uruware)'. 6) Cron is run by batches (size=10). 7) Add tests. The suffixes -manual and -notification are used to differentiate between EDI documents generated manually and those generated automatically. This is useful to determine whether the document was created by a user or by an automated process, also helps users identify its origin more easily and also it is useful for debugging and tracking purposes. Task Adhoc side: 43467 Task latam side: 1355 Forward-Port-Of: odoo/enterprise#99556 Forward-Port-Of: odoo/enterprise#86829
This update resolves a bug that prevented payments using the 'Own Checks' method in the Bank journal with foreign currencies, causing invalid operation errors. The fix corrects a typo in the code, ensuring accurate accounting entries and proper payment balancing. This improves the reliability of payments for Latin American businesses.
Original PR description
Setup: - Install l10n_latam_check - Set an outstanding payment account on the outgoing payment method "Own Checks" in the "Bank" journal. - Activate a foreign currency Steps to reproduce: - Go to "Accounting/Vendors/Payments" - Create new payment with a foreign currency, with the journal "Bank" and "Own Checks" as payment method - Create 3 "Checks" lines (whatever dates or amounts) - Post -> Invalid Operation: The entry is not balanced. Issue: - There appears to be a typo in `_l10n_latam_check_split_move`, where `liquidity_balance` is used instead of `liquidity_balance_total` opw-5151228 Forward-Port-Of: odoo/odoo#236768
This update resolves an issue where changes to many2one fields within the website builder weren't consistently reflected across related displays and saved correctly. The fix ensures that the `data-oe-many2one-id` attribute is properly copied during replication, guaranteeing accurate data synchronization and preventing display or saving errors.
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 Forward-Port-Of: odoo/odoo#235080
This update optimizes how Odoo calculates lead stages, addressing a performance issue that increased query counts. The change ensures the correct stage is associated with a lead's team, resulting in faster lead stage updates and improved system responsiveness. This enhances the overall user experience for sales teams.
Original PR description
**Issue:**
Query count increases as `lead.stage_id.team_ids` needs to be used to ensure the current `stage_id` is related to the current lead `team_id`.
```py
@api.depends('team_id', 'type')
def _compute_stage_id(self):
for lead in self:
if not lead.stage_id or (lead.team_id and lead.stage_id.team_ids and lead.team_id not in lead.stage_id.team_ids):
lead.stage_id = lead._stage_find(domain=[('fold', '=', False)]).id
```
related: https://github.com/odoo/odoo/commit/ce8fdbb1989703715663d334662a87d1900a28feThis update corrects a bug where vendor bill payment statuses remained incorrect after deleting or resetting payments. Previously, the bill status didn't update properly, even after the payment was removed. This fix ensures that the Vendor Bill status accurately reflects the payment's state, resolving a discrepancy with customer invoices.
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 Forward-Port-Of: odoo/odoo#237479 Forward-Port-Of: odoo/odoo#234725
This update fixes an issue where invoice lines were incorrectly reconciled across different customers during POS sessions. Previously, settling payments mixed invoices from various partners, leading to inaccurate reporting. Now, reconciliation is limited to the specific partner within the POS session, ensuring accurate financial records.
Original PR description
Invoice lines to be reconciled are not tailored to the single partner while the session lines do. That causes reconciliation to happen between different partners. To reproduce: Create an invoice of 100 to Customer 1 and an invoice of 200 to Customer 2. In a pos session, go to Customer 1, settle 50 on that invoice. Go to Customer 2, settle 100 on their invoice. Close register. => Lines from different customer are reconciled together. task-5346644 Forward-Port-Of: odoo/enterprise#100131
This update resolves an issue that occurred when translating content within the website editor. Specifically, adding a 'BR' tag after a translated string caused a save error. The fix removes translation branding elements during website editing to prevent this conflict and ensure proper saving of changes.
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-5234578
Forward-Port-Of: odoo/odoo#236674This update fixes an issue where refunds for products tracked by serial numbers incorrectly included all serial numbers from the original order, even when a partial refund was made. Now, users can correctly select the serial numbers to refund, ensuring accurate tracking and preventing over-reporting of returned items. This improves the reliability of our point-of-sale system.
Original PR description
When refunding an order that contains a product tracked by serial number if you refund less than the total quantity of the product in the order all the serial numbers of the original order would be set anyway. Also you were not able to select the serial numbers to refund. Steps to reproduce: ------------------- * Create product P1, storable, tracked by serial number * Create 2 Serial Numbers SN1, SN2 for P1 * Create a POS order with 2x P1 (SN1, SN2) * Pay and validate the order * Refund the order, set quantity of P1 to 1 * Validate the refund > Observation: The refund order contains P1 with SN1 and SN2, and you cannot edit the serial numbers. Why the fix: ------------ We now allow to select the serial numbers when doing a refund and only show the serial numbers that were in the original order. We also select by default the same number of serial numbers as the quantity to refund. opw-4965171 Forward-Port-Of: odoo/odoo#236394 Forward-Port-Of: odoo/odoo#230778
This update ensures that company locations are correctly created during Odoo upgrades, preventing errors that could occur when the `mrp_subcontracting` module isn't loaded early enough. Previously, a company might be created without a designated location, leading to upgrade failures. This fix guarantees locations are created, improving upgrade stability.
Original PR description
During an upgrade, it could happen that some companies are created before this module is loaded. That means the override of `_create_per_company_locations` is not called and the company is created with an empty `subcontracting_location_id`. That can lead later to issues as that value was not expected to be empty. To reproduce: - On 16, install `onboarding`[^1], `l10n_de`, `mrp_subcontracting` with demo data. - Upgrade to 17. Module `l10n_de` will have created a company with empty subcontracting location. - Upgrade to 18. The upgrade will break during a call to `_create_or_update_sequences_and_picking_types` in `stock` because of the empty value. [^1]: onboarding is necessary to ensure l10n_de is loaded before mrp_subcontracting because of the dependencies. Forward-Port-Of: odoo/odoo#236149
This update resolves an issue where drag-and-drop file uploads to the composer were failing within Picture-in-Picture calls. The fix ensures the composer is correctly enabled in PiP mode, allowing users to seamlessly share files during calls. This improves usability for users engaging in calls.
Original PR description
Before this commit, when in a discuss call with Picture-in-Picture, drag-drop of files in composer was not working on odoo tab. Steps to reproduce: - start a call from discuss app - open call view in picture-in-picture - drag a file and drop in the main tab of conversation with call => no dropzone visual and cannot drop file to composer This happens because condition for dropzone was on meeting view being open, which assumes this comes from fullscreen mode but the meeting view can also be shown in picture-in-picture mode. This commit fixes the issue by disabling composer outside of meeting view when explicitly in fullscreen mode. That way picture-in-picture mode is not mistakenly preventing the dropzone on odoo tab.
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. The fix ensures that when this parameter is modified, the dynamic fields associated with analytic plans are correctly created and removed, preventing data inconsistencies and errors. This improves the reliability of project accounting.
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#234987
Forward-Port-Of: odoo/odoo#231981