Daily updates from Odoo
Monday, November 24, 2025
250 changes
16 changes
New functionality added to Odoo
This change adds a new module to create and send electronic delivery guides (e-Remitos) for Uruguay. It lets users generate compliant delivery documents from stock operations, include corrections and addenda, and receive the approved PDF back from the local EDI provider.
Original PR description
This pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking…
This pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking operations. The main changes include configuration for managing and generating e-Remitos according to Uruguayan fiscal requirements. **Steps to create an e-Remito** 1. Install l10n_uy_edi_stock 2. Create a new delivery order. 3. Select a value for the field "Type of Operation". This will indicate that we are creating the electronic document, and also add a tab named "UY EDI" with some configurations for the e-Remito. <img width="1231" height="585" alt="image" src="https://github.com/user-attachments/assets/c4c0baa8-8f9b-4453-b0c0-ce1b1503c536" /> <img width="1211" height="565" alt="image" src="https://github.com/user-attachments/assets/c827f787-27ed-4d55-a660-42a6b617e7df" /> The field "Addenda and disclosures" works as in invoices, the user will be able to select the addenda to add to the e-Remito report. The field "EDI Reference" is used to indicate that the e-Remito is a correction of another, so it will suggest previous e-Remitos made for the same partner, and it will add "Correction of e-Rem XXX" on the addenda. 4. Validate the delivery order and click on "Create Delivery Guide" button. This will send the document to DGI for validation and add the PDF returned by Uruware. <img width="1705" height="618" alt="image" src="https://github.com/user-attachments/assets/8bb36b08-ab08-4240-b3bb-f593a7f2a462" /> Odoo Task 1334 Adhoc Task 53147 Forward-Port-Of: odoo/enterprise#99397 Forward-Port-Of: odoo/enterprise#89706
Enhancements to existing features
This update lets Point of Sale and self-ordering connect to local devices like Epson printers and the black box over regular HTTP in modern Chrome browsers. As a result, businesses no longer need to install certificates just to keep these local connections working.
Original PR description
*: pos_self_order, pos_epson_printer Feature: https://chromestatus.com/feature/5152728072060928 Since Chrome 142, a new feature called “Local Network Access” has been added, allowing local IPs to be contacted via HTTP without mixed content errors. This means that certificates are no longer required to contact Epson printers or the black box. Forward-Port-Of: odoo/odoo#236916 Forward-Port-Of: odoo/odoo#235702
This update improves how GSTR-2B processing handles certain errors and avoids retrying records that are already in an invalid state. As a result, background jobs run more reliably and waste less time on records that cannot be processed successfully.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
This update makes website builder tests use the same real content and processing as the live editor, instead of relying on copied snippets. It reduces the risk of test mismatches and helps ensure future changes are validated against the actual website experience.
Resolved issues and error corrections
This update brings the spreadsheet component to a newer version and includes several fixes that improve everyday use. It addresses issues like scrolling on iOS, editing behavior, button sizing, and better handling of read-only views and sheet names with spaces.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4f8366721 [REL] 18.4.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/4f8366721 [REL] 18.4.18 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/83c393f62 [FIX] Spreadsheet: fix scroll on ios [Task: 5270869](https://www.odoo.com/odoo/2328/tasks/5270869) https://github.com/odoo/o-spreadsheet/commit/948c51e86 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/3ce3152f7 [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888) https://github.com/odoo/o-spreadsheet/commit/16b2e4115 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) https://github.com/odoo/o-spreadsheet/commit/e4b3ebef8 [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) https://github.com/odoo/o-spreadsheet/commit/62dfe8a88 [FIX] composer: Enter/Tab confirm when assistant is force-closed [Task: 5153666](https://www.odoo.com/odoo/2328/tasks/5153666) https://github.com/odoo/o-spreadsheet/commit/2a23dddf4 [FIX] reference_type: add single quotes for sheet names with spaces [Task: 5244798](https://www.odoo.com/odoo/2328/tasks/5244798) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
The image editor now handles image load events more reliably by using the correct built-in event handling in the template. This prevents leftover listeners from building up and helps avoid small performance or behavior issues when working with images.
Original PR description
In `AutoResizeImage`, a listener for the load of an image was made with a `useEffect`, but it was not correctly cleaning. It should return a function that remove the listener not directly call `removeListener`, and it should remove the same listener that was added. This commit uses the `t-on-load` in the template instead. task-5190618
This update prevents the Italian "Libro Giornale" template from affecting all journal reports. As a result, regular journal exports keep their journal names and other companies’ reports are no longer altered by this local customization.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
This update fixes an error that could appear when users changed the website header to the Search Bar template and then selected Center or Right alignment. It removes incorrect view references so the alignment options work normally again in the Website Editor.
Original PR description
Problem: When setting Center or Right alignment while using the Search Bar Header Template, an error message will occur due to an invalid xpath in the respective views. Purpose: Remove the invalid xpaths. Steps to Reproduce on Runbot: 1. Enter the Website Editor. 2. Select the Header and change the Template to Search Bar. 3. Attempt to change the Alignment to Center or Right. opw-5150348
This fix prevents date placeholders from appearing to the wrong signer in multi-signer documents. It helps each person see only the fields that are meant for them, reducing confusion during the signing process.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970 Forward-Port-Of: odoo/enterprise#98256
This change prevents validation errors when a duplicated delivery is edited to use a different product. It ensures pricing is calculated only from stock movements of the same product, so returns and subsequent validations work correctly.
Original PR description
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product. The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error. Steps to reproduce: - Create storable products P1 and P2: - Category: AVCO - P1 UoM: Unit - P2 UoM: Dozen - Create a sale order with 1 unit of P1 - Confirm the SO - Open the generated picking - Duplicate it → a new picking is created and still linked to the same SO - Change the product on the duplicated picking to P2 - Confirm and validate it - Create a return on this picking and validate it - Go back to the original picking of P1 and try to validate it Problem: A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)” This fix ensures that average price is computed only using stock moves belonging to the same product. opw-5027089 Forward-Port-Of: odoo/odoo#236706
This change fixes an issue where registering payments for many invoices at once could run out of memory. It reduces the amount of data loaded during tax checks, making batch payment processing more reliable and less likely to fail.
Original PR description
### Description: When trying to register a payment for multiple invoices, it is possible to trigger an Out Of Memory error. This is caused by the constraint `_validate_taxes_country`, calling the compute `_compute_tax_country_id` on all of the moves. To avoid that, we just retrieve the field we need rather than fetching everything. ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#235749
This update fixes missing settings on several Philippine custom tax tags so they are treated correctly in tax calculations. As a result, tax reports should now reflect the right amounts instead of showing false values.
Original PR description
This commit sets tax_negate to true to (-QAPA, -QAPB, -SAWTA, -SAWTB). They were missing and impacted a tax report falsely. opw-5157090 Forward-Port-Of: odoo/odoo#236725
This fix prevents partner names from being recalculated unnecessarily when editing or deleting lines in a bank statement reconciliation. It helps keep previously corrected entries stable and avoids unexpected changes on related lines.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670 Forward-Port-Of: odoo/enterprise#99999
When editing a website, Discuss bubbles will now shift out of the way instead of sitting on top of the editor. This makes it easier to select and edit page snippets while still keeping conversation bubbles visible.
Original PR description
Before this commit, discuss bubbles would appear on top of the editor when editing a website. I was therefore be difficult to select some snippets, especially when the user had a lot of conversations at the same time and he wanted to keep the discuss bubbles visible. This commit shift the discuss bubbles on edit to solve the issue. task-4266898 Forward-Port-Of: odoo/odoo#184671
The Profit and Loss report has been corrected to include a newly introduced expense category called Other Expenses. This ensures financial reports show all relevant expenses for companies using that account type, preventing missing amounts in the report.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Profit & Loss Report. Since l10n_be is the only CoA which uses this account type, the issue was not uncovered until OXP testing days. Forward-Port-Of: odoo/enterprise#94219
This update fixes an issue where the French balance sheet could become unbalanced when using the 2024 chart of accounts. It ensures missing income and expense amounts are correctly included so retained earnings are calculated properly and reports stay consistent.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
14 changes
Enhancements to existing features
This change improves how Odoo records screencasts by switching to a lossless H.265 format and removing a setting that was making files much larger without improving quality. The result is more reliable recordings for comparing test runs, while also reducing storage use compared with the previous output.
Original PR description
- `-g 0` turns out to significantly increases file size without increasing quality (apparently it makes every frame an i-frame) - lossless video seems useful for comparing different runs, and while it *is* costly it's pretty reasonable for screencasting (5~6 times the size of a normal output, but a third the size of current outputs) - "lossless h264" (per ffmpeg) does not seem to actually be lossless - lossless av1 does work (and is slightly smaller than h265), but the libsvtav1 shipped by ubuntu does not support it, and libaom is *extremely* slow, so that might be something to revisit in a few years Testing on the main flow tour (desktop), - the current setting generates a 40MB file - removing `-g 0` generates a 2.6MB file, quality seems about the same - h264 pseudo-lossless yields a 9.4MB file - h265 lossless is 16.9MB - av1 (libsvtav1) is 2.5MB - av1 lossless (libaom) is 13.2MB
This update improves how GSTR-2B issues are classified and handled, so one previously unrecognized error is now treated as a warning instead of causing confusion. It also stops background jobs from reprocessing records that are already in an error state, reducing unnecessary work and making the process more reliable.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
This change makes the system much faster when finding delivery records linked to lots/serial numbers. It reduces database work and avoids repeated processing, which means better performance and shorter wait times for large inventories.
Original PR description
### Description: This refactoring replaces the recursive calculation in `_find_delivery_ids_by_lot` with an iterative process. This change significantly reduces the amount of database queries by prefetching and batching all required lines in a single pass, and it also eliminates the overhead caused by repeated recursive function calls. ### Benchmark: | Total Lots | Before | After | |------------|--------|--------| | 69 | 1 sec | 106 ms | | 1152 | 1 min | 5 sec | ### Reference: opw-5096599 Forward-Port-Of: odoo/odoo#236541 Forward-Port-Of: odoo/odoo#233478
Resolved issues and error corrections
This update brings the spreadsheet component to a newer version with several fixes to improve day-to-day use. It addresses issues like button sizing, accidental interaction in read-only spreadsheets, editing mode behavior, and side panel refresh behavior.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/57b11b85d [REL] 18.3.27 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/57b11b85d [REL] 18.3.27 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6487f6d0e [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888) https://github.com/odoo/o-spreadsheet/commit/8ec4b1cd1 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/e076525ba [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) https://github.com/odoo/o-spreadsheet/commit/e8d8bcd9b [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
The mobile Documents board now displays folders and documents more cleanly, removing awkward empty space when both appear together. It also improves the Recent folder so items use the available width properly and can be scrolled to view all documents. This makes browsing documents on phones smoother and easier to use.
Original PR description
This commit fix several issue in kanban mobile view: - When a folder has folders AND documents, there is a huge gap between the two because of the kanban ghost records. - In the 'Recent' folder, folders and documents doesn't take all width. - In the 'Recent' folder, we can't scroll to see all the documents. Task-4963198 Forward-Port-Of: odoo/enterprise#99810 Forward-Port-Of: odoo/enterprise#90647
This change fixes an issue where certain POS items, including gift cards and e-wallet products, could fail to appear on the product screen. By aligning the product category setup, the POS now loads the expected items correctly and avoids test failures in the runbot environment.
Original PR description
Before this commit: ======================= The `whiteboard_pen` product had no assigned category, while the main POS configuration was limited to specific categories. As a result, `whiteboard_pen` was not displayed on the product screen. When no products were loaded, special products like gift cards and e-wallets also not shown,showing the `Load Sample` button instead of products. This caused tour tests expecting gift cards on the screen to fail. After this commit: ====================== Assigned the same product category to whiteboard_pen as used in the POS configuration. This ensures that the product appears on the product screen and special products like gift cards also load properly, preventing the tour test from failing. Runbot Error: 233434, 233435
This change ensures the Italian "Libro Giornale" report only applies its custom layout to the correct country. As a result, the standard journal report keeps showing journal names properly for other companies and reports are no longer affected by the Italian customization.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
This fix prevents an error that could appear when a duplicated delivery is changed to a different product and then returned. It ensures stock cost calculations only use records for the same product, so users can validate deliveries and returns without unexpected failures.
Original PR description
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial…
When duplicating a delivery linked to a sale order and changing the product on the duplicated picking, validating the return could lead to an error when validating the original picking of the initial product. The issue occurred because the average price computation was mixing stock moves of different products when consuming valuation layers, leading to a UoM singleton error. Steps to reproduce: - Create storable products P1 and P2: - Category: AVCO - P1 UoM: Unit - P2 UoM: Dozen - Create a sale order with 1 unit of P1 - Confirm the SO - Open the generated picking - Duplicate it → a new picking is created and still linked to the same SO - Change the product on the duplicated picking to P2 - Confirm and validate it - Create a return on this picking and validate it - Go back to the original picking of P1 and try to validate it Problem: A UserError is raised due to mixed products in the average price computation, resulting in a “Expected singleton: uom.uom(...)” This fix ensures that average price is computed only using stock moves belonging to the same product. opw-5027089 Forward-Port-Of: odoo/odoo#236706
This fix updates several Philippine custom tax tags so they are properly treated as negative amounts in tax reporting. It prevents tax reports from showing incorrect totals for affected transactions.
Original PR description
This commit sets tax_negate to true to (-QAPA, -QAPB, -SAWTA, -SAWTB). They were missing and impacted a tax report falsely. opw-5157090 Forward-Port-Of: odoo/odoo#236725
This change fixes an issue that could cause the system to run out of memory when registering payments for many invoices at once. It makes the payment validation step more efficient so large batches can be processed more reliably.
Original PR description
### Description: When trying to register a payment for multiple invoices, it is possible to trigger an Out Of Memory error. This is caused by the constraint `_validate_taxes_country`, calling the compute `_compute_tax_country_id` on all of the moves. To avoid that, we just retrieve the field we need rather than fetching everything. ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#235749
This change prevents Point of Sale from getting stuck in a repeated update when both the default preset and the available presets are empty. It makes the system handle this empty-state case safely, avoiding a freeze during configuration updates.
Original PR description
The condition `config.default_preset_id.id not in config.available_preset_ids.ids` is equivalent to True when both default_preset_id and available_preset_ids are empty. This triggers an infinite loop as assigning with `|=` triggers a nested write. 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#231378
This update corrects how periodic values are chosen in reports that contain sections, such as the Luxembourg tax return. It ensures the report uses the right source period so submitted amounts reflect the intended period instead of the current month.
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-5163352Miscellaneous changes
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#236609 Forward-Port-Of: odoo/odoo#236469
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#236609 Forward-Port-Of: odoo/odoo#236469
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#99971 Forward-Port-Of: odoo/enterprise#99887
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#99971 Forward-Port-Of: odoo/enterprise#99887
3 changes
Resolved issues and error corrections
This fix ensures that when a filter is enabled on a composite cash basis report, it is also applied to its sections. As a result, the filter now shows up properly in the user interface and behaves consistently across related report parts.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100148
This update corrects the way the Italian “Libro Giornale” report template is applied so it only affects the intended local report. As a result, standard journal reports keep showing journal names correctly when the Italian reporting module is installed.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
This fix ensures that when a filter is enabled on a composite report, the same filter is also enabled on its underlying sections. As a result, the filter will appear correctly in the interface and behave consistently across report views.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100135
32 changes
Enhancements to existing features
This update makes the test runner behave more gracefully when no tests are found, logging a message instead of raising an error. It also improves visibility in headless runs by showing the results of all top-level test suites at the end of execution, making debugging easier.
Original PR description
[FIX] web: Hoot - remove error if no tests This commit replaces the error thrown if there is no test found by a log. --- [IMP] web: Hoot - log root suites at end of run This commit makes the unit test runner log all root suites results after each test run, only in headless mode. Forward-Port-Of: odoo/odoo#236647
The TDS entry form now asks for the TDS Section before the Base Amount. This makes the input flow clearer and prevents the amount from changing after users have already entered it.
Original PR description
Before this commit: - In the TDS Entry wizard the Base Amount field appeared before the TDS Section field, causing users to enter a manual amount that later changed once the TDS Section is selected, since base amount is computed based on it. After this commit: - The TDS Section field is now placed before the Base Amount field to ensure a predictable input flow. task-5312252 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change improves how GSTR-2B processing handles certain return-period errors and prevents background jobs from retrying records that are already in an invalid error state. As a result, the system avoids unnecessary processing and reduces noise from known issues.
Original PR description
Before this commit: - `RET2B1017` error code was not handled. - Cron methods `_cron_get_gstr2b_data` and `_cron_gstr2b_match_data` processed all records with status: - `"waiting_reception"` - `"being_processed"` - Records with blocking level `"error"` were still being processed by cron. After this commit: - Added handling for `RET2B1017` and mapped it to `"warning"` level. - Updated cron domain filters to exclude records where `gstr2b_blocking_level = "error"`. - Cron jobs now skip invalid/error-state return periods, preventing unnecessary processing. Forward-Port-Of: odoo/enterprise#100150 Forward-Port-Of: odoo/enterprise#99378
We updated how the signature block is registered so it can be used reliably in the Email Builder and Mass Mailing tools. This fixes an issue where the signature option could stop appearing after recent editor changes, helping users keep their content consistent across templates.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **community: https://github.com/odoo/odoo/pull/190616** task-4224624
This update makes Spanish POS receipts use a consistent, consecutive number when they are not turned into invoices. It helps avoid gaps or resets in the displayed ticket number, so the receipt numbering better matches official requirements and is more reliable across devices.
Original PR description
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
Resolved issues and error corrections
This change prevents editor placeholders from being inserted inside buttons and links. As a result, editable buttons like the product “Add to Cart” button keep their correct alignment and appearance when edited.
Original PR description
The "add to cart" button in the showcase view of products in website_sale is a block with `contenteditable=true` and a selection placeholder was inserted in it, messing up its layout (alignment). It shouldn't be there in the first place, as buttons and links are not meant to contain paragraphs. This commit prevents the insertion of selection placeholders in buttons and links. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents a crash that could happen when users press backspace while editing the people assigned to a task in kanban views. It improves reliability during a common editing action and avoids an unexpected error screen.
Original PR description
How to reproduce: - Go to project tasks - Edit the list of people assigned to a task - Press backspace Current behavior: Traceback Expected behavior: No traceback task-5189783 Forward-Port-Of: odoo/odoo#235997 Forward-Port-Of: odoo/odoo#235489
This fix corrects planned hours in Timesheets / Planning analysis reports so shifts are only counted when they overlap with an employee’s working hours. This prevents hours from being incorrectly attributed to the wrong month when a shift ends outside business hours.
Original PR description
### Steps to reproduce: - Create an employee with fixed working schedule from 8 to 5 - Create a Planning shift for this employee that starts in a month and ends in the first day of the next month outside of working hours (e.g. Sept30th 8AM -> Oct1st 2AM) - Navigate to Timesheets / Planning analysis reports - Notice October has been taken into consideration in the report's planned hours ### Cause: The query we are using for the timesheets/planning report doesn't take working hours into consideration it only cares about the date. So if the shift ends in October 1st we are taking it into account whether it is inside working hours or not. ### Fix: Add a condition to the where clause to check the working hours and if the record lays in this period or not. opw-5089052 Forward-Port-Of: odoo/enterprise#96846
The website now hides mega menu links when the linked content is not available to the current visitor, both on desktop and mobile. This avoids empty dropdowns and keeps the navigation cleaner and less confusing for users.
Original PR description
Before this commit, when setting the mega menu content visibility, the navbar link would still appear even if the user does not have access to the mega menu content. This commit hides the navbar link for the mega menu in the mobile and desktop view when the user does not have access to the mega menu content, in order to prevent unnecessary elements in the navbar. Steps to reproduce the bug: - Add a mega menu element in the navbar - Open the mega menu - Set the mega menu content visibility to conditional (logged in) - Open the website while logged out (The mega menu link is here but the content is not displayed. However, the dropdown is still opened but it is empty.) task-3992066 Forward-Port-Of: odoo/odoo#235714 Forward-Port-Of: odoo/odoo#179454
This update prevents long product attribute text from spilling outside the product card in the catalog view. It keeps the product image and details neatly contained, improving the layout and making the interface more reliable for users.
Original PR description
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on…
Steps to reproduce: 1. Go to Products > Create a new product. 2. Add or create a new attribute with a long text value. 3. Go to Sales > Open any quotation. 4. In the sale order line, click on "Catalog" and search for the created product. Issue: - The product image and attribute value text overflow outside the product card in the kanban view, causing layout misalignment and breaking the UI design. <img width="647" height="225" alt="image" src="https://github.com/user-attachments/assets/afc592bb-e25a-4d81-882b-0e7cc7ad1064" /> Cause: - The inner div containing the attribute text lacked overflow control, allowing long text to exceed the container width and pushing other elements. Solution: - Added the Bootstrap class `overflow-hidden` to the div element to ensure the image and text remain properly contained within the card layout. <img width="587" height="171" alt="image" src="https://github.com/user-attachments/assets/580ce1e5-42bd-4c2d-b6bf-14315759626d" /> opw-5222002 Forward-Port-Of: odoo/odoo#235680 Forward-Port-Of: odoo/odoo#235214
This update brings the spreadsheet component to a newer version with several bug fixes and small usability improvements. It addresses issues like scrolling on iOS, read-only behavior, formula handling, border display, and pivot/table limits, helping users work more reliably across devices and spreadsheet scenarios.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5bdbccc9 [REL] 19.0.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f5bdbccc9 [REL] 19.0.11 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6b7c8085a [FIX] Spreadsheet: fix scroll on ios [Task: 5270869](https://www.odoo.com/odoo/2328/tasks/5270869) https://github.com/odoo/o-spreadsheet/commit/1a9de79be [FIX] borders: preserve side borders when combining External and All [Task: 5270171](https://www.odoo.com/odoo/2328/tasks/5270171) https://github.com/odoo/o-spreadsheet/commit/42fa2e10a [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/dd6124730 [FIX] spreadsheet: fix button height [Task: 5253888](https://www.odoo.com/odoo/2328/tasks/5253888) https://github.com/odoo/o-spreadsheet/commit/c23e4925d [FIX] functions: ignore vectorized SUBTOTAL [Task: 5261987](https://www.odoo.com/odoo/2328/tasks/5261987) https://github.com/odoo/o-spreadsheet/commit/7edc3b50b [FIX] release: make lastest [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/d59fcbf0d [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) https://github.com/odoo/o-spreadsheet/commit/2b5cd53d1 [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) https://github.com/odoo/o-spreadsheet/commit/7ae8c7666 [FIX] composer: Enter/Tab confirm when assistant is force-closed [Task: 5153666](https://www.odoo.com/odoo/2328/tasks/5153666) https://github.com/odoo/o-spreadsheet/commit/eccc2e02f [FIX] reference_type: add single quotes for sheet names with spaces [Task: 5244798](https://www.odoo.com/odoo/2328/tasks/5244798) https://github.com/odoo/o-spreadsheet/commit/b95dcae83 [FIX] pivot: raise pivot size limit [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update corrects how the Italian "Libro Giornale" report custom template is applied so it only affects the intended report and company context. As a result, regular journal reports keep showing journal names correctly even when the Italian localization is installed.
Original PR description
The custom template for the report "Libro Giornale" was neither inheriting with primary neither using conditions on the country code. Therefore, the xpaths applied were for all the journal reports, whatever the company. For example, when exporting the regular journal report, the names of the journals no longer appeared once the module l10n_it_reports was installed on a database. opw-5217520 Forward-Port-Of: odoo/enterprise#100045
This update prevents an error when opening the translation tool on invoice terms and conditions. It ensures translatable text fields load correctly, so users can translate invoice content without seeing a traceback.
Original PR description
With l10n_gcc_invoice, the narration field on invoice (the Terms & Condition part) becomes translatable. However, when opening the translation widget, a traceback happens as the "fields" (the text-to-fill part) to load don't have a specified name. opw-5269869
The link popup no longer shows an unwanted horizontal scrollbar. This makes the editor look cleaner and keeps the action buttons neatly within the popup area.
Original PR description
### Description of the issue/feature this PR addresses: - The link popover started showing a horizontal scrollbar after the addition of the wand (magic) icon. The combined horizontal margins (`mx-1`) on all action buttons caused the total width to slightly exceed the popover’s fixed size. ### Desired behavior after PR is merged: - To fix this, removed the `mx-1` margins and used `gap-2` with `justify-content-end`, ensuring all buttons fit within the defined width without triggering overflow. task-5261323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
GCC invoices now display product line names in both English and Arabic again when both translations are available. This restores the expected bilingual presentation on printed invoices, helping customers read documents in the language they prefer.
Original PR description
### Issue: In GCC invoices the product names are not in both languages. ### Steps to reproduce: - Install "l10n_sa" and switch to a Saudi company - Have a product with its name translated in both…
### Issue: In GCC invoices the product names are not in both languages. ### Steps to reproduce: - Install "l10n_sa" and switch to a Saudi company - Have a product with its name translated in both English and Arabic - Create an invoice with this product, print it - The product name is only displayed in the language of the partner ### Cause: [This refactor](https://github.com/odoo/odoo/commit/1cddcab8b8626b34c437a51d320b0a3e4698dae7) removed the [part of the code responsible for displaying the product in both languages](https://github.com/odoo/odoo/blob/f9090fff6b3564c0d7ce2363a283b81ea10b3906/addons/l10n_gcc_invoice/views/report_invoice.xml#L286-L293). Now only `line.name` is displayed. ### Solution: We use the same XML architecture as in 18.0. As `line.name` is composed of several fields combined we need to check if the English and/or Arabic name is in `line.name` to display it or not. We use a replace in the xpath to add `dir="rtl"` on `line.name`. This ensure that when the partner lang is Arabic then `line.name` is displayed right to left. ### Note: `line.name` can contain other field like `description_sale` or `description_purchase` that will still be displayed in only one language. opw-5219783
This fix ensures table numbers appear correctly on receipts generated from self-orders in restaurant POS. It matters because staff and customers can now quickly identify the correct table on printed receipts, reducing confusion and mistakes.
Original PR description
**Steps to reproduce:** * Set up a `POS` with the restaurant module. * Go to `Configuration → Settings → Self Ordering` and set `QR Menu + Ordering`. * Set `Service At` to `Table` and `Pay After` to `Meal`. * Download QR codes from the `Get QR Codes` button in the POS restaurant interface. * Create a self-order by scanning the QR code. * Print the receipt. **Observed behavior:** When a self-order is created, the table number does not appear on the receipt, while orders created from the POS interface correctly display the table number. **Cause:** The receipt template only checks `table_id` to display the table number, but self-orders only have `self_ordering_table_id` set. **Fix:** Update the receipt header template and logic to also use `self_ordering_table_id` as a fallback when `table_id` is not set, ensuring the table number is correctly displayed on self-order receipts. opw-5250724
This update restores the expected payment rule for standard ISO 20022 payments, ensuring the correct service level is used by default. It helps avoid payment rejection or processing issues when sending payments outside the SEPA zone or in non-EUR currencies.
Original PR description
Since commit [[1]], the Service Level is set to NURG only when using the specific `iso20022_se` payment method. However, the previous expected behavior was to set the Service Level to NURG automatically whenever a payment was in a non-EUR currency or targeted a non-EU IBAN, regardless of the specific ISO20022 variant. This commit restores the logic to set the Service Level to NURG for all standard ISO20022 payments. This fix doesn't check anymore if a payment is in non-EUR currency or target a non-EU IBAN. Using iso_20022 activate it by default. opw-5095483 [1]: https://github.com/odoo/enterprise/commit/67593e5ff9b3a5187a1535bc8fc89590b4c9401e Forward-Port-Of: odoo/enterprise#100061
This fixes an issue where editing or deleting one line in a bank statement could unintentionally change the partner on other lines. The update keeps previously edited lines stable while still recalculating partner information when using the reconcile action, improving consistency for accounting users.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670 Forward-Port-Of: odoo/enterprise#99999
This update fixes a styling issue that could break page assets when the text editor app was not installed. It ensures the color picker keeps working and the interface remains usable in databases without that optional component.
Original PR description
Some scss variables used in color_picker.scss were defined in html_editor, thus breaking assets if html_editor was not installed. Steps to reproduce: - Create a new database - Uninstall html_editor - Scss assets are broken task-5230908 Issue: https://github.com/odoo/odoo/issues/234507
This update corrects how planning weeks are compared when schedules span multiple years. It prevents incorrect calculations in forecasted planning and helps ensure allocated hours are computed accurately.
Original PR description
Steps to reproduce: 1- install project_forecast 2- run test_creating_a_planning_shift_with_flexible_hours_allocated_hours_are_correct => test fail Source: When slots span across multiple years (e.g., 2019 → 2026), https://github.com/odoo/odoo/blob/f8f72b15598576f5870e49879e96fc5c127a6100/addons/resource/models/resource_resource.py#L338 this comparison becomes invalid, it compares week numbers only, ignoring the year. For instance, week 23 of 2019 is considered after week 18 of 2026. Fix: compare year and week
This change prevents the system from sending duplicate and growing numbers of network requests when a POS scale updates its weight over longpolling. It keeps the scale working reliably by ensuring only one request is active per event, which avoids request failures after repeated use.
Original PR description
Steps to reproduce: 1. Setup a scale in a POS. 2. Disable the WebRTC connection so that longpolling is used. 3. Try to weigh with the scale in the POS. Expected behaviour: - There is one HTTP call per weight event, and the scale continues to work no matter how many times the weight changes. Actual behaviour: - The amount of HTTP calls doubles every time the weight changes. Before long, a limit is reached and the requests start to fail. This behaviour was due to the `addListener` method being called again inside the listener callback, calling the poll method. The original poll call would also start to poll again, leading to two polling requests. The fix is to check in the poll method that listening has not restarted during the handling of the callback. If so, we don't try to poll again. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue that could cause the system to run out of memory when registering payments for multiple invoices at once. It improves reliability for large payment batches and helps avoid interruptions during accounting operations.
Original PR description
### Description: When trying to register a payment for multiple invoices, it is possible to trigger an Out Of Memory error. This is caused by the constraint `_validate_taxes_country`, calling the compute `_compute_tax_country_id` on all of the moves. To avoid that, we just retrieve the field we need rather than fetching everything. ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#235749
The product page now correctly hides the alternative products section when there are no alternatives to show. This fixes an issue where editing the section in Studio could leave an empty block visible to shoppers.
Original PR description
### Issue: In this issue, alternative products will continue to be shown even if the product has no alternative products, due to editing alternative products using studio. #### To reproduce: 1- Create a product with an at least one alternative product. 2- On product shop page, using studio, edit the description of alternative products. 3- Remove alternative products of the product. 4- As seen, the alternative products section is still shown, even though it is empty. ### Cause: This is due to `oe_structure` which doesn't copy the `t-if`. This makes `t-if=product.alternative_product_ids` to be missed in the new inherited view created by studio. opw-5253884
This change adds an extra step to a barcode manufacturing test so it matches the expected user flow more reliably. It helps prevent a flaky test failure, improving confidence in the stock barcode manufacturing process without changing business behavior.
Original PR description
Test `test_no_split_uncompleted_done_move` is failing non-deterministically after odoo/enterprise#98184 Runbot: 234351
This update prevents an error in Stripe webhook processing for expense payments when virtual card shipping details are missing. It helps keep expense-related payment updates running smoothly and avoids interruptions caused by unusual card data.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict
The Signature option has been moved to a shared category so it can be used consistently across editors. This fixes an issue where Mass Mailing could no longer access the Signature plugin, improving reliability for email creation.
Original PR description
### Description of the issue/feature this PR addresses: - The Signature Plugin was defined in the sign module by extending the html_editor plugin under the basic_block category. - The mass_mailing builder removed config.plugins, preventing the Signature Plugin from working. ### Desired behavior after PR is merged: - The category is now defined in html_editor and renamed to modules so other modules can also use it. - Mass Mailing: - Signature Plugin is registered in `mass_mailing-plugins` for mass_mailing. - For simple editor, Signature Plugin is registered in `basic-editor-plugins`. **enterprise: https://github.com/odoo/enterprise/pull/75612** task-4224624
This fix stops the Bahrain tax reports from generating two identical closing entries when users submit either the full or simplified return. It matters because it prevents duplicate accounting records and reduces the risk of confusion or manual cleanup.
Original PR description
The full and simplified reports will generate 2 identical closing entries. A better solution to choose which return to use will be done in the task 5232715 task-5123564
This fix prevents an error that could happen when users try to create a contract before the employee record has been saved. The New Contract button is now only shown once the employee exists, avoiding a failed action and improving the hiring flow.
Original PR description
Currently, an error occurs when the user clicks the New Contract button. Steps to Reproduce ([Video](https://drive.google.com/file/d/11xSVGvMLJSvEfnHjixquP94wH29eVqMT/view)): - Install the `hr`…
Currently, an error occurs when the user clicks the New Contract button. Steps to Reproduce ([Video](https://drive.google.com/file/d/11xSVGvMLJSvEfnHjixquP94wH29eVqMT/view)): - Install the `hr` module. - Go to `Employees` > click `New` > do not fill in the employee name. - In the `Payroll` section, set the contract `start and end dates`. - Click `New Contract` and select a date outside that date range. `IndexError: tuple index out of range` This error occurs because the user clicks the New Contract button before the employee record is created. Since the employee is not created, the employee ID is False. Then it attempts to create a contract with this False ID [1]. When the system tries to find the employee’s version using this False ID, no version is found, raise the error [2]. This commit ensures that the Add Contract button is visible after the employee record is created. [1]- https://github.com/odoo/odoo/blob/bf0e135d55136dd6f263d281a09b7f4d08d7fc5b/addons/hr/static/src/components/button_new_contract/button_new_contract.js#L45-L48 [2]- https://github.com/odoo/odoo/blob/bf0e135d55136dd6f263d281a09b7f4d08d7fc5b/addons/hr/models/hr_employee.py#L554 sentry-7033637685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When editing a website, Discuss chat bubbles no longer sit on top of the page content and interfere with selecting snippets. This makes it easier to edit pages while still keeping conversations visible.
Original PR description
Before this commit, discuss bubbles would appear on top of the editor when editing a website. I was therefore be difficult to select some snippets, especially when the user had a lot of conversations at the same time and he wanted to keep the discuss bubbles visible. This commit shift the discuss bubbles on edit to solve the issue. task-4266898 Forward-Port-Of: odoo/odoo#184671
This fix ensures that the new "Other Expenses" account type is included in the Profit and Loss report. As a result, businesses using this account type will now see their expense totals reported correctly and completely.
Original PR description
In saas-18.3 a new account type was added: "Other Expenses" These accounts are excluded from the account many2one field to make it easier to find relevant expense accounts for vendor bills. Issue: This account type is not included in the Profit & Loss Report. Since l10n_be is the only CoA which uses this account type, the issue was not uncovered until OXP testing days. Forward-Port-Of: odoo/enterprise#94219
This fix ensures the traceability report shows the right component for each finished serial-numbered product when multiple units are made in one manufacturing order. It prevents components from appearing under every finished product, which could otherwise give a misleading view of what was actually consumed.
Original PR description
Steps to reproduce: ------------------- 1. Create 1 product that is serialized, add a BoM that has one component 2. Create a manufacturing order for multiple units of the finished product, each…
Steps to reproduce: ------------------- 1. Create 1 product that is serialized, add a BoM that has one component 2. Create a manufacturing order for multiple units of the finished product, each consuming one component 3. Generate the serial numbers for the finished products, then validate the manufacturing order 4. Open the traceability report, every component is listed under every finished product, making it seem that every component was used to manufacture each unit Observation: ----------- The traceability use the consume_line_ids to know what element the move_line consumed : https://github.com/odoo/odoo/blob/10e5ac9943a68f03a31c149ff14ade1cf3937e3d/addons/mrp/models/stock_traceability.py#L32 the assigning of the consume_line_ids every finished moves form the order will have inside their consume moves, all the conmponent from all the finished_moves, which create this situation: https://github.com/odoo/odoo/blob/1e8d8b51b2b5b99f6fe9f01b8219441863111763/addons/mrp/models/mrp_production.py#L1852-L1853 This issue appeard on 19.0 since this commit allowed to manufacture several serial number with only one MO: https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e#diff-4ea85ad9b881e3fdcbc31b3674f4c79965fd643e79c1e746c934ad824e4eccceL98 before the issue was not present since all element had different mo orders. Why the fix: ------------ I think is too risky to create new moves lines for each product, it would impact other elements than just the traceability. Could also try to change the values directly inside the tracability files -> working in this. opw-5133629
Annual corporate tax returns now use the actual fiscal year dates when a company has a fiscal period longer than 12 months. This prevents the wrong yearly closing from appearing and ensures the return is scheduled for the correct year and deadline.
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#100160 Forward-Port-Of: odoo/enterprise#100034
30 changes
Enhancements to existing features
This update changes how Odoo sends messages to IoT Boxes so each device gets its own message instead of a combined one. It helps ensure delivery and reporting features continue to work reliably with stable IoT Box versions.
Original PR description
In order to ensure ws compatibility with stable IoT Boxes versions, we now split websocket messages to send one per IoT identifier, instead of one targeting multiple ones. related: odoo/odoo#234175 Forward-Port-Of: odoo/enterprise#100127
The system now logs only the message type and device for printer websocket events, instead of recording the full message payload. This reduces log noise and helps avoid oversized logs caused by large print data, making troubleshooting easier for support teams.
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
Odoo now includes an additional application information field when sending payment requests to Adyen. This helps ensure the external platform details are transmitted correctly, improving compatibility and reliability of payment processing.
Original PR description
Add applicationInfo to the payload sent to Adyen, ensuring that externalPlatform is correctly transmitted. A test was added to verify that applicationInfo is present in the payload and that the payment request succeeds as expected. task-5157863 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233075
This change lets users import journal items that reference inactive accounts without the import failing. It prevents unnecessary errors and makes data imports more reliable when older or archived accounts are involved.
Original PR description
When importing journal items, if an item targets an inactive account, the import is causing an excessive error. We shall ignore the active/inactive flag in such a case. task-5350113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix ensures that when a delivery is made from a lot with a zero cost, the system keeps that lot’s zero value instead of incorrectly falling back to an average product cost. This prevents stock valuation from showing the wrong amount and keeps inventory accounting accurate.
Original PR description
**Problem:** when selling a product valued by lot and chosing a lot with a value of 0 the average value of the product is used instead of 0. **Steps to reproduce:** - make sure your warehouse is in…
**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.
**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button
**Current behavior:**
the value of the stock valuation layer is -5
**Expected behavior:**
it should be 0
**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277
**fix:**
deleting the lot.standard_price condition
is not possible because when the lot is created
at delivery it has no standard_price and in this
case we want to use the standard_price of the
product.
(see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)
opw-5077671This change fixes an issue where clicking the Pack button in purchase catalogs could sometimes appear to do nothing. The quantity is now calculated more reliably so packaging can be added correctly even when decimal values are involved.
Original PR description
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a…
Issue ----- Clicking the "pack" button in the catalog sometimes seems not to work and the product quantity remains unchanged. Steps to reproduce ----- - Enable packagings in settings - Create a product - Set a vendor "Mom" - Add a packaging of some decimal number, eg 22.68 - Create a new purchase from "Mom" - Open the catalog - Click the product once - Click the "pack" button 4 times (# of clicks required depends on the pack amount) > The last click did not increase the product quantity Cause ----- Javascript floats are sometimes an approximation of the value rather than the value itself. This means that when we do https://github.com/odoo/odoo/blob/0611a74cb52ca639b683ef158f8b4f2f347d08ad/addons/purchase/static/src/product_catalog/kanban_record.js#L33-L34 the flooring might sometimes get a close approximation and end up flooring down the packaging quantity. In our example, `this.productCatalogData.quantity` should be `68.04` but is actually `68.03999999999999`. This leads to `this.productCatalogData.quantity / packaging.qty` == `2.9999999999999996` `Math.floor` then rounds it down to 2 so we end up with 2 + 1 = 3, which is the current packaging quantity so nothing changes. ----- Ticket: opw-5130865 Forward-Port-Of: odoo/odoo#235706
The portal chatter rating widget now scrolls normally instead of staying fixed at the top and covering other elements. This makes the message area cleaner and easier to use when customers scroll through portal conversations.
Original PR description
Before this PR, the rating widget in the portal chatter overlapped other elements when scrolling because it was positioned as sticky at the top of the screen. This PR fixes the layout by adjusting the widget’s positioning, ensuring that only the composer remains sticky while the rating widget scrolls normally. Before: https://github.com/user-attachments/assets/4ad2eb34-0773-4812-ad74-cdb49f0bafa0 After: https://github.com/user-attachments/assets/f2e9df3e-7305-4582-b1e5-f7ec9fafea94 task-[5138987](https://www.odoo.com/odoo/project/1519/tasks/5138987)
This update refreshes the spreadsheet component to its latest version and includes several bug fixes. It improves behavior in read-only sheets, helps editing mode switch correctly when selections change, and prevents side panel data from carrying over incorrectly when the underlying model changes.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4ef5b75e [REL] 18.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b4ef5b75e [REL] 18.0.49 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/725b0ccc3 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/e3c5deac2 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) https://github.com/odoo/o-spreadsheet/commit/f76210a1e [FIX] SidePanel: reset initial props on Model change [Task: 5059484](https://www.odoo.com/odoo/2328/tasks/5059484) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update prevents an error in the restaurant tip screen when closing a tab after payment lines have been adjusted. If no payment line is currently selected, the system now safely uses the first available one so the flow continues without interruption.
Original PR description
Steps: --- - Enable Tips and "Add tip after payment" in restaurant. - Open a session and add any product(s). - Go to payment and add two card lines (first with full amount, second with 0). - Click on "Close Tab". Issue: --- - After redirecting to the Tip Screen, a traceback appears. Cause: --- - Clicking "Close Tab" clears all 0-amount payment lines. This can leave no selected payment line, but the Tip Screen still tries to access it. Fix: --- - Use the selected payment line if available, otherwise fallback to the first payment line. task-5095825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users sending invoices through Chorus Pro will now see a clear alert if the extra module is not installed. This helps avoid missing validation checks and reduces the risk of submitting documents with incomplete verification.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects when editor hints and action buttons appear in empty paragraphs. It now hides them when a tab is present, and shows them properly when a paragraph only contains formatting marks like bold or italic tags, improving the editing experience and reducing confusion.
Original PR description
Description of the issue this PR addresses: - Hint and power buttons are incorrectly shown or hidden in empty blocks when the block contains a Tab or only empty formatting tags (`<strong>, <em>, <u>, <s>`). Current behavior before PR: - Pressing Tab in an empty block leaves the hint and buttons visible. - Empty paragraphs containing only formatting tags do not show the hint and buttons. Desired behavior after PR is merged: - Hint and power buttons are not shown when a block contains a Tab. - Hint and power buttons are correctly visible when a block contains only empty formatting tags. task-5062294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Analytic entries now use the company currency when they are created, instead of relying on the currency of the journal item. This prevents small rounding differences from causing mismatched analytic amounts and improves accounting accuracy.
Original PR description
Analytic line values are determined by the balance of a journal item, not their amount_currency. https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/models/account_move_line.py#L3230-L3237 However, the journal item's currency is referenced when creating an analytic line. This can cause discrepancies when the journal item's currency has a different rounding factor (`rounding`). [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5171681) opw-5171681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234797
This change fixes an issue where pressing Backspace at the start of an empty quote could accidentally remove a Table of Contents block. Empty quotes are now handled more safely, helping users edit documents without losing nearby content by mistake.
Original PR description
### Steps to reproduce: - Create a new Project task. - Insert a Table of Contents (e.g., /tableofcontent). - Insert a quote below it (e.g., /blockquote). - Place the cursor at the start of the empty quote and press Backspace. - The Table of Contents is removed. ### Desired behavior after PR is merged: - Empty blockquote is converted into a base container when backspace is pressed. task-5246130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects the link between Uruguayan electronic documents and their source records, so the system now keeps the document number in sync when invoices or stock transfers are processed. As a result, the PDF generated by the external service can be found and attached properly after the document is accepted.
Original PR description
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the…
### Issue: When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway. ### Steps to reproduce: - Install 'l10n_uy_edi' and switch to an Uruguayan company - In the Settings change 'UCFE Web Services' to 'Testing' and input credentials - Create a new invoice, confirm and send, click 'Generate CFE' - The CFE status is accepted but the PDF from Uruware is not on the record ### Cause: This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set. In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same. Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)). ### Solution: We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`. opw-5272776
This update prevents an error that could occur when creating an annotation in the General Ledger while using Arabic. The date is now saved in a format the system can process reliably, so users can add annotations without interruption.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656
This update fixes two loyalty card issues: archived cards now appear properly in the inactive filter, and they can no longer be used to keep claiming rewards. It helps ensure that deactivated loyalty cards stay deactivated and reduces confusion for users managing promotions and rewards.
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
Fixed an issue where placeholder text was not appearing in the Related Company field on contact forms. This improves clarity for users entering new contacts by showing the expected guidance text in the field.
Original PR description
**Issue:** Fields using the res_partner_many2one widget with a placeholder do not display the placeholder text. **Steps to reproduce:** 1. Install `contacts` module 2. Go to Contacts 3. Create new 'Individual' contact 4. Notice just below the name, Related Company field placeholder is not visible. **Cause:** Props are not passed correctly in PartnerAutoComplete component **Solution:** Use the correct prop reference (props.placeholder) when passing the placeholder to the PartnerAutoComplete component, ensuring it is properly rendered. opw-5153125 Forward-Port-Of: odoo/odoo#231445
Composite reports now correctly pass selected filter settings down to their sections, so the filter appears and works as expected in the user interface. This brings these reports in line with the standard behavior used by other report filters and avoids confusing inconsistencies for users.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100148
This change avoids a memory overload that could happen when users register payments for many invoices at once. It makes the payment process more efficient by only loading the data needed for the check, improving reliability for larger batches.
Original PR description
### Description: When trying to register a payment for multiple invoices, it is possible to trigger an Out Of Memory error. This is caused by the constraint `_validate_taxes_country`, calling the compute `_compute_tax_country_id` on all of the moves. To avoid that, we just retrieve the field we need rather than fetching everything. ### Reference: opw-5152687 Forward-Port-Of: odoo/odoo#235749
This change ensures that when a filter is enabled on a composite financial report, the same filter is also activated on its underlying sections. As a result, the filter now appears correctly in the user interface and behaves consistently with other report filters.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236893
Users can now add annotations to accounting report lines even when their language uses non-Latin numerals. This prevents an error when saving the message in the chatter, improving reliability for localized environments.
Original PR description
Currently, an error occurs when a user tries to add an annotation on a line in a localization that uses a non-Latin numbering system. **Steps to produce:** - Install accountant with demo data and language ar_001 - Open General Ledger report in accounting - Click Annotate on any line and type a message **Error:** `psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٢٠"` **Solution:** - Change the datetime object to use Latin numbers, as the system expects. *Backport of https://github.com/odoo/enterprise/pull/99270* opw-5250261
This fix prevents outstanding accounts from being cleared when a journal’s currency is changed. It ensures the existing payment method settings remain intact, avoiding missing account information after currency updates or bank synchronization.
Original PR description
Changing the currency on a journal triggers the compute of inbound/outbound method lines, which clears the method lines before reasign the default method lines. This leads to the loss of any outstanding account set on the method lines. Steps: - Have a bank journal with outstanding accounts set on the payment method lines - Change the currency (in our case, this is the bank sync that changed the currency of the journal) -> Outstanding accounts are missing on the payment method lines, even if the accounts currency is the same as the journals or no currency is set on the accounts. opw-5175794
This update fixes a text selection problem inside table cells when users hold Shift and click. It makes selection behave like a normal browser, reducing frustration and preventing incorrect text highlighting while editing tables.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Property imports now handle fields that users cannot access because of access rules or group restrictions. This prevents import failures in those cases and makes the import process more reliable.
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.
This change fixes an issue where unregistering a Nemhandel user could leave the account stuck and prevent it from being picked up again. It also avoids an error when someone tries to unregister manually, making the process more reliable for users.
Original PR description
If you unregister a Nemhandel user, it won't ever be picked up by the user db. And trying to unregister by hand will give a traceback. This is due to mismatch between Exception types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
We fixed an issue in Peru electronic invoicing where adding a partner reference could trigger validation errors from the tax operator. The system now sends the correct partner information for the local format, helping invoices process successfully.
Original PR description
In the Peru UBL, adding a reference to a partner would cause an error from the OSE (code 3090). This was because the call to super in _get_partner_party_identification_vals_list would add the partner.ref as an ID, which is incorrect in the Peruvian context. Removed the call to super which did not bring any other information. ticket-5193233
Fixed an issue where a filter enabled on a composite report could fail to appear in the interface if its underlying sections were not configured separately. This makes report behavior consistent and helps users see the expected options when working with grouped analytics reports.
Original PR description
When using a composite report whose sections aren't used independently, enabling that filter on the composite report needs to enable it on their sections as well, else it won't show in the UI. This is the standard behavior for all report filters. Forward-Port-Of: odoo/enterprise#100135
This update corrects Spanish Facturae exports so withholding amounts are always sent as positive values. As a result, invoices with withholding taxes are less likely to be rejected by FACE, improving submission reliability for users in Spain.
Original PR description
## Issue: The `TotalTaxesWithhold` field in the exported XML could be negative, causing FACE to reject the document. ## Cause: A previous change (https://github.com/odoo/odoo/pull/229236) added `values['tax_amount_currency']` to `TotalTaxesWithhold` without converting it to a positive value: https://github.com/odoo/odoo/blob/88b7ee6d9d2a7fe96512da0a7eaf8efcf9020ee1/addons/l10n_es_edi_facturae/models/account_move.py#L449 ## Steps to reproduce: - Install `l10n_es_edi_facturae` - With the ES company, create an invoice with a product and a withholding tax (e.g., 15% WHI) - Confirm the invoice and Send (Facturae) - Open the XML attached in the chatter - Observe that `TotalTaxesWithhold` is negative opw-5220205
This fix ensures prices stay accurate when a sales order is settled in Point of Sale using products with units that cannot be grouped together. It prevents incorrect totals caused by a mismatch between the quantity and the unit price during the conversion process.
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
The color picker now correctly shows custom colors that were already used on the page, including for background colors. This restores the expected behavior and makes it easier for users to keep styling consistent when editing pages.
Original PR description
Before this commit, the colorpalette for the background color would not display custom colors already on the page. The issue appeared in 17.0 and worked in 16.0 before the conversion of wysiwyg to owl. github.com/https://github.com/odoo/odoo/pull/118966 The "getEditableCustomColors" method was not forwarded and therefore we used the default function, returning nothing. Steps to reproduce the issue: - Add a snippet - Set the background / font color of the snippet to a custom color - Add another snippet - Open the colorpicker for the text color (The colorpicker have access to the custom color set above) - Open the colorpicker for the background color (The colorpicker does not have access to the custom color set above) task-3806989 Forward-Port-Of: odoo/odoo#180335
5 changes
Enhancements to existing features
This change makes Google Places autocomplete more flexible when searching for customer information. Businesses can now adjust the search type to better find locations or establishments, which should reduce cases where no result is returned for valid queries.
Original PR description
Description of the issue/feature this PR addresses: We use the google search autocomplete for completing our clients informations in the application Contact, but for some reasons almost all the times the autocomplete was not working, it was not able to find an address (the same query worked on google search engine). Current behavior before PR: On trying to search the business of a client by name, most of the time no result found. Desired behavior after PR is merged: I would be able to change the base behaviour of the google search api with a custom module by changing the parameter of the method, by changing the types from "address" to "geocode|establishment". This change will change nothing for thoses who don't need this improvement, because the old comportement was kept as a default parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update refreshes the spreadsheet component to its latest version and includes a couple of usability fixes. It prevents interactions in read-only spreadsheets and improves how the editor switches modes when the cursor or selection changes, reducing confusing behavior for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/498c3fcb1 [REL] 17.0.78 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/498c3fcb1 [REL] 17.0.78 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1e758de59 [FIX] headers_overlay: disable interaction in read-only mode [Task: 5182854](https://www.odoo.com/odoo/2328/tasks/5182854) https://github.com/odoo/o-spreadsheet/commit/60a66b680 [FIX] composer: change mode to editing when composer cursor selection changes [Task: 5226615](https://www.odoo.com/odoo/2328/tasks/5226615) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
Automatic payment follow-ups will now use an active user instead of an archived one when choosing who sends the message. This prevents errors and avoids follow-ups being sent under inactive staff accounts.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159
The Romanian SAFT report was incorrectly using the supplier account for both customers and suppliers. This update ensures customer records are reported with the proper receivable account, improving the accuracy of the export and reducing the risk of incorrect tax/reporting data.
Original PR description
### Issue: In the SAFT report both the Customer and the Supplier have the same account. ### Cause: In the XML there was probably a typo and both have `property_account_payable_id` as account. ### Solution: For the `Customers` node, use `property_account_receivable_id`. opw-5144009
Code cleanup and technical improvements
This change reorganizes how changes to a product’s standard cost are prepared and applied. It makes the process easier for other parts of Odoo to hook into, improving flexibility for future stock and valuation updates without changing the main business flow.
Original PR description
To make it hookable when some vaccum values of a product needs to be change a separate method and prepare values method was created This was split from the initial PR https://github.com/odoo/odoo/pull/160527 cc @pfertyk --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr