Daily updates from Odoo
Tuesday, November 25, 2025
90 changes · 19.0
Security fixes and vulnerability patches
This update resolves an issue preventing users in the 'invoicing and banks' security group from accessing key account reports. The changes add necessary security rules, specifically for the 'account basic' group, ensuring these reports are accessible for partner ledger, aged receivable/payable, and tax unit reports.
Original PR description
Some report must be accessible by user with the invoicing and banks security group. The menu items are there but when clicking on it, an access error is thrown. This commit will add the security rules for the group account basic for horizontal group (for the partner ledger and aged receivable/payable) and the tax unit (for the tax report) opw-5218948
New functionality added to Odoo
This update introduces a new reporting feature for Ireland, specifically the Return of Trading Details (RTD). This allows Irish businesses using Odoo to accurately track and report their trading activity as required by local regulations. This change supports compliance and provides essential reporting capabilities for Irish users.
Original PR description
WIP This PR adds a new report for Return of Trading Details (RTD) for Ireland task-5184653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces a new integration with Intervat, allowing Belgian companies to electronically submit VAT declarations. Additionally, it provides access to MyMinfin, enabling users to download previous VAT declaration files (PDF & XML) after submission. This improves compliance and simplifies record-keeping for our Belgian customers.
Original PR description
This commit ad new EDI integration for Intervat and MyMinfin api's, usable only for Belgian companies. Intervat: this api is used to send electronic vat declarations. MyMinfin: this api is used after a declaration submission, it allow the user to fetch and download files (pdf & xml) from previous submitted declarations. Linked: https://github.com/odoo/odoo/pull/221070 task-4624148
This update adds support for Local Network Access (LNA) in our Point of Sale (POS) and self-ordering systems. With Chrome 142, LNA allows direct communication with devices like Epson printers and the internal ‘black box’ without requiring secure certificates, simplifying setup and improving reliability. This change enhances the user experience and ensures seamless operation.
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
Enhancements to existing features
This update enhances account reports to ensure they only display journals relevant to the currently selected company when multi-company accounting is enabled. Previously, reports could inadvertently include data from other companies' ledgers. This change improves report accuracy and simplifies the user experience for businesses managing multiple companies.
Original PR description
When multi-company, if multi-ledger is visible to one company, exclude journals of other companies when opening the report. task-5180393
This update enhances the multi-company ledger feature by preventing confusion when multiple companies are selected. It now includes the company name in the journal selection options, making it easier to manage and understand which companies are associated with a particular ledger.
Original PR description
* When a company is selected on multi-ledger, exclude other companies journal from excluded journals view. * When multi-ledger is visible for all companies, add the company name to the tags list and autocomplete options of the excluded journals to avoid confusion. task-5180393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update introduces new tax groups for AR withholdings and perceptions, enhancing tax tracking accuracy. By creating distinct groups for withholdings and aligning with existing sales/purchase structures, this change simplifies tax reporting and improves data management. It also corrects naming conventions for key accounts.
Original PR description
Update id and tax groups on tax csv files. Before this change all the perceptions and withholdings were in the same tax group. New withholding tax groups are created on…
Update id and tax groups on tax csv files. Before this change all the perceptions and withholdings were in the same tax group. New withholding tax groups are created on addons/l10n_ar_withholding/data/template/account.tax.group-ar_base.csv and addons/l10n_ar_withholding/data/template/account.tax.group-ar_ex.csv 1) Replace/unify "ARBA" with "PBA" and "Provincia de Buenos Aires (P. Buenos Aires)" 2) Replace/unify "CABA" with "CABA" and "Ciudad Autónoma de Buenos Aires" 3) Multiply the tax groups for AR withholdings taxes: a) To improve tax tracking. Currently, all withholdings are grouped into a single group, making it very difficult to retrieve all taxes related to a specific withholding. The tax group concept fits this need well. b) Aligns with how tax groups are structured for sales/purchases. c) Also, the current single withholding group is incorrectly named "VAT Withholding". 4) Fix the name of the generic account from "Default VAT Payable/Receivable Account" to "Default Tax Payable/Receivable Account" Task Adhoc side: 57644 Task Latam side: 1361 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
- `-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 ub
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 Forward-Port-Of: odoo/odoo#236710
This update improves the HTML editor's syntax highlighting by adding a dedicated read-only component, ensuring highlighting is visible even when the editor is in read-only mode. It also refactors the underlying component structure for better efficiency and maintainability, addressing several related improvements and bug fixes.
Original PR description
The syntax highlighting plugin cleans itself up on save so the `pre` is not dependent on Prism's css. But we still want to see the highlighting in readonly mode, so this adds a readonly version of the component in order to parse the `pre` in readonly as well. This also refactors the syntax highlighting embedded component so it uses an embedded state instead of reinventing it with `commitToHost`. task-5159286 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update simplifies the Peppol Registration Wizard by removing unnecessary warnings and placeholders. Specifically, the outdated 'in' migration process has been removed, streamlining the registration experience for users. This change focuses on clarity and efficiency within the wizard.
Original PR description
In the Peppol Registration Wizard: - ~Warning banner should only show up when endpoint as been filled~ - Remove placeholder - ~Remove the "in" migration~ Ref PR for master: odoo/odoo#234088 Task [link](https://www.odoo.com/odoo/project/967/tasks/5170831?debug=assets) task-5170831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235982 Forward-Port-Of: odoo/odoo#234087
This pull request optimizes how Odoo handles employee data, resulting in faster loading times and improved responsiveness when working with employee records. The changes enhance the performance of the HR module, leading to a smoother user experience. This is a general performance improvement.
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
This update ensures that the same optional fields related to vehicle assets are consistently shown on both Receipts and Vendor Bills within the Enterprise module. This improves data clarity and simplifies processes for users managing fleet assets. The change aligns field visibility across related documents.
Original PR description
This commit ensures that the same optional fields are displayed consistently on both Receipts and Vendor Bills. Updated the visibility of the following fields: - vehicle_id (Vehicle) task-5349202
This update ensures that key optional fields – like deductible amounts, vehicle IDs, landed costs indicators, and purchase order references – are consistently displayed on both Receipts and Vendor Bills. This improves data clarity and simplifies processes for users managing financial transactions across multiple modules.
Original PR description
Modules modified - account, account_fleet, stock_landed_costs, purchase This commit ensures that the same optional fields are displayed consistently on both Receipts and Vendor Bills. Updated the visibility of the following fields: - deductible_amount (Professional %) - vehicle_id (Vehicle) - is_landed_costs_line (Landed Costs) - purchase_order_id (Purchase Order) task-5349202
Resolved issues and error corrections
This update resolves a problem in the avatar card test that was caused by pre-existing activities set up when the demo data was installed. By removing these activities during the test setup, the test now runs reliably and accurately, ensuring the multi-company activities function correctly.
Original PR description
Before this commit, the admin user had some pre-defined activites when installed with demo data, this was interfering with the test since it is using the count of activities to ensure the correct functioning of the multi-company activities. Now, we simply unlink all activities in the setup of the test to ensure its stability. fixes-runbot-234343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where reordering lists with multiple pages would cause elements to temporarily disappear. The fix prevents incorrect page loading when deleting the last item on a page, ensuring lists refresh correctly and data is consistently displayed. This improves the user experience for all users managing sortable lists.
Original PR description
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you…
****Behavior:**** **Current:** When adding an element to any reorderable empty list, then deleting it, then adding two new ones, and lastly trying to reorder them. They will disappear until you reload the list. This is occurring since list can be presented in multiple pages, the length of which is defined by the variable limit and the current page is represented by offset (multiple of limit) and when the last element of a page is deleted, we load the previous page (deduce limit from offset), the issue is that there isnt any checks that we are not currently on the first page of the list, and thus we change offset to a negative number (0-limit) which results in an empty list when trying to load the ids of the records (which happens when we reorder the list, and not when adding new elements which explains why they only disappear at that moment) **Steps to reproduce:** (example with sale orders but works with any manually sortable list) - Create a Sale Order - Add any product - Delete it - Add any two combination of product or sections - Swap the order of both - You'll see the elements disappear, when reloading the page they should come back. opw-5191103
This update resolves a test failure related to leave requests, specifically during weekends. The fix ensures the test accurately reflects the system's behavior by using a consistent, non-weekend date for leave calculations. This improves the reliability of our leave management process.
Original PR description
In this commit, we fixed the failed runbot test test_reset_leave_work_entries. The test is failing during weekends since we are requesting and approving leaves using datetime.now(). As a fix, we choose a specific date for the leave (non weekend date). task-5353513. Related to 247070 (runbot errorr) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where code blocks within the HTML editor's syntax highlighting weren't properly aligned with their surrounding code blocks. By applying the same styling to the textarea as the pre element, the alignment is now consistently maintained, improving the user experience for writing and viewing code.
Original PR description
When writing in a code block, we need to ensure its textarea's contents are aligned with its pre's. This could get broken when the textarea's contents would wrap and the pre's wouldn't. To fix this, we set the css property `white-space` of the textarea to 'pre' (as is done for the pre element), so that both elements behave the same way. task-5354848 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a potential issue with how images were loaded and resized within the HTML editor. The change ensures that image listeners are properly cleaned up, preventing performance problems and ensuring the editor functions smoothly. It replaces a custom listener with Odoo's built-in `t-on-load` for improved stability.
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 Forward-Port-Of: odoo/odoo#232987
This update resolves a technical issue that could have caused the Point of Sale system to become unresponsive (freeze) when certain settings were empty. The fix prevents an infinite loop triggered by a specific condition, ensuring smoother operation and preventing potential disruptions to sales transactions. This improves system stability and reliability.
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#231649 Forward-Port-Of: odoo/odoo#231378
This update significantly speeds up the process of finding deliveries associated with stock lots. By optimizing a key database query, the system now responds much faster, particularly when dealing with a large number of lots. This improves overall system responsiveness and efficiency.
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#236773 Forward-Port-Of: odoo/odoo#233478
This update resolves an issue where changing a journal's currency caused outstanding account information to disappear from payment method lines. This change ensures that account details remain accurate after currency adjustments, preventing data loss and maintaining financial reporting integrity. The fix was triggered by a bank sync updating currency.
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 Forward-Port-Of: odoo/odoo#234008
This update resolves an error that prevented users from sending messages in Chatter when using the Arabic localization (ar_001). The issue stemmed from a mismatch in date formatting expectations, specifically requiring Latin numerals. This change ensures proper message sending functionality for all supported languages.
Original PR description
Currently, an error occurs when a user tries to send log notes or messages in a localization that uses a non-Latin numbering system. **Steps to produce:** * Install `accountant` with demo data and…
Currently, an error occurs when a user tries to send log notes or messages 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 the chat bubble on any item to open Chatter and type a message. **Error:** `ValueError: time data '٢٠٢٥-١٢-٣١' does not match format '%Y-%m-%d'` **Root cause:** * This error happens because field [1] is a date field and expects a format using Latin numerals (as seen in [2]). Using Arabic numerals makes the text display right-to-left, causing an error when stripping the string at [3]. **Solution:** * Change the datetime object to use Latin numbers, as the system expects. [1]: https://github.com/odoo/enterprise/blob/5a7cf0f8c3817b5b0fafb798e55f290a53478dfb/account_reports/wizard/mail_compose_message.py#L11 [2]: https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/odoo/tools/misc.py#L536 [3]: https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/odoo/orm/fields_temporal.py#L158 sentry-7015787743
This update resolved a bug where the 'whiteboard pen' product and gift cards were not appearing correctly on the POS screen. By assigning a standard product category, the system now correctly displays these items, preventing tour tests from failing and ensuring a smooth user experience.
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 Forward-Port-Of: odoo/odoo#233563
This update prevents a display error in the project portal when users try to unfollow a task that hasn't been saved. The fix ensures the 'Unfollow' button is hidden for new, unsaved tasks, improving the user experience and preventing a technical error.
Original PR description
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. -…
Currently, an error occurs when a portal user opens a shared project and clicks the `Unfollow` button in the chatter of a `new(unsaved)` task. **Steps to produce:** - Install the `project` module. - Open the project app and create a new project with at least one task. - From the project’s `dropdown menu(⋮)`, select `Share Project`. - Add a `collaborator: Joel Willis`, with `Edit access mode`, copy the `public link`, and click `Share Project`. - Open the shared link in an incognito window and sign in as a `portal user`. - Open the project folder > open any task > click `New` > click `Unfollow` button. **Error**: `ValueError: Expected singleton: project.task()` **Root cause:** The Unfollow button at [1], is displayed even when the task record is not yet saved (`props.threadId` is `undefined`). At [2], the method is called on an empty recordset, causing an `error`. **Fix:** This commit prevents the error by ensuring the `Unfollow` button is hidden when the record is `unsaved`. [1]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/static/src/project_sharing/chatter/portal_chatter_patch.xml#L7-L14 [2]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/models/project_task.py#L2022 No task ID Forward-Port-Of: odoo/odoo#236633
This update prevents a bug where optional products in quotes could have negative quantities when rapidly reducing their amounts. The fix ensures that optional product quantities always remain at zero, improving data accuracy and preventing potential issues in sales processing. This resolves a minor user experience problem.
Original PR description
**Steps to reproduce:** * Install the **Sale Management** module with demo data. * Create a Quotation and set the *Quotation Template* to **Office Furniture**. * Open the **Preview** mode of the…
**Steps to reproduce:** * Install the **Sale Management** module with demo data. * Create a Quotation and set the *Quotation Template* to **Office Furniture**. * Open the **Preview** mode of the quotation. * Scroll to the bottom where **Optional Products** are listed. * Increase the quantity of an optional product from the initial value of zero. * Rapidly click the **minus (-)** button multiple times. **Observed behavior:** * The quantity of an optional product goes below zero when the **minus button** is clicked rapidly. **Cause:** https://github.com/odoo/odoo/blob/5ab45d45073463495e517aca9fd061415a73e893/addons/sale_management/views/sale_portal_templates.xml#L9-L16 * The decrease button is bound using classes that is not updated in the DOM after quantity changes rapidly. As a result, rapid clicks continue triggering the handler on the outdated element, causing multiple unexpected decrease events and allowing the quantity to become negative. **Fix:** * Add a guard to prevent the quantity from dropping below zero, ensuring the minimum quantity always remains zero. --- opw-5250851 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an error that occurred when the system automatically cleaned up data related to withhold payments. The fix ensures that linked data is properly disconnected before cleanup, preventing database errors. This improves the stability of the EC company accounting processes.
Original PR description
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** *…
Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard. **Steps to replicate:** * Install `l10n_ec_edi` and change company to `EC company` * Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm * Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post * Set system time to future date > Run `Base: Auto-vacuum internal data`. Refer video [1] for replication steps. **Error:** `psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line' ` **Root cause:** * The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours. * However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error. **Solution:** * Unlink the lines first and then unlink the wizard. [1]: https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 [3]: https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 [4]: https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427 sentry-6253783256 Forward-Port-Of: odoo/enterprise#99653
This update resolves a memory issue that occurred when processing sales documents in the RS (Romania) region. The fix pre-fetches key data, preventing the system from running out of memory and improving processing speed. This ensures accurate and efficient handling of RS EDI transactions.
Original PR description
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in…
Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory records ``` sagu_3267671=> select count(id) from account_move; count --------- 1034179 (1 row) ``` ``` File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine return needle(*args) File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed') File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__ self.compute_value(recs) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value records._compute_field_value(self) File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value return super()._compute_field_value(field) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value fields.determine(field.compute, self) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine return needle(records, *args) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp> values = [first(value[name]) for value in values] File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__ return self._fields[key].__get__(self, self.env.registry[self._name]) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__ return super().__get__(records, owner) File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__ recs._fetch_field(self) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field self.fetch(fnames) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch fetched = self._fetch_query(query, fields_to_fetch) File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query self.env.cache.insert_missing(fetched, field, values) File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing field_cache.setdefault(id_, val) MemoryError ``` upg-3267671 opw-5246681 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235919
This update fixes an issue where users couldn't find UNSPSC codes by typing partial numbers. The system now uses a flexible search method, allowing users to enter any part of the code and receive relevant product results. This enhances the accuracy and usability of product categorization.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_mx** modules. * Open any product form view. * Navigate to the **Accounting** tab. * In the *UNSPSC Category* field, start typing a numerical code such as **'10101500'**. **Observed behavior:** * No results are returned, even though the corresponding UNSPSC code exists in the database. **Cause:** * The `_search_display_name` method used an exact match (`=`) on the `code` field, preventing any partial or prefix-based lookup during user input. **Fix:** * Replace the exact-match domain on `code` with a partial match using `ilike`, allowing users to find UNSPSC codes by typing any part of the numerical sequence. opw-5244705 Forward-Port-Of: odoo/enterprise#99651
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fi
Original PR description
Before this commit, quickly triggering the opening of the file viewer multiple times (e.g. double-click on an attachment) caused a crash. This happens because the `createFileViewer` hook generates a `fileViewerId` on initialization. When `open()` is called, it registers the component using this specific ID. If `open()` is triggered a second time while the component is still registered (or being registered), the registry throws an error because duplicate keys are not allowed. This commit fixes the issue by calling `close()` at the beginning of the `open()` function. This ensures that any existing `FileViewer` instance associated with this hook is removed from the registry before a new one is added. task-5262556
**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 sa
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-5077671
Forward-Port-Of: odoo/odoo#234764This update resolves an issue where preparation printing failed when no order was selected in the POS service. The fix prevents a traceback during preparation, ensuring UrbanPiper orders are correctly sent for printing. This improves the reliability of the restaurant's preparation workflow.
Original PR description
Steps to reproduce: - Set up UrbanPiper and a preparation printer in the restaurant. - Open the Ticket Screen from the Floor Screen. - Accept an UrbanPiper order. Issue: - Traceback occurs when sending the order for preparation if no order is currently selected in the POS service. Fix: - Prevent error during preparation printing when no order is selected. ---- Remove redundant `modeUpdate` logic from `categoryCount` computation Task-5241128
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty tags are created before and after the formatted <span><a></a></span> with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty tags remain in the DOM. Description of the issue this PR addresses: - In the removeFeffs method, FEFF characters are replaced with empty text nodes, which can lead to unwanted empty elements and
Original PR description
Steps to Reproduce: - Create a link in the editor (e.g., "abc"). - Select all and change the font size from 14 to 80. - Two empty tags are created before and after the formatted <span><a></a></span> with only FEFF Characters. - Change the font size again (e.g., back to 14). - Multiple empty tags remain in the DOM. Description of the issue this PR addresses: - In the removeFeffs method, FEFF characters are replaced with empty text nodes, which can lead to unwanted empty elements and empty text nodes being left in the DOM. Desired behavior after PR is merged: - Empty text nodes resulting from FEFF replacement are now properly removed, preventing leftover empty elements in the DOM. task-5097770 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233909
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong c
Original PR description
Before this PR: - Sending invoice/vendor bill to eTIMS would send null item codes if products weren't registered. - `View Product(s)` button in validation messages opened standard product variant view with generic product fields instead of eTIMS-specific fields. - When sending multiple invoices via batch processing, product registration used incorrect company context (in `self.env.company`) instead of the specific invoice's company, causing products to be registered to the wrong company's eTIMS system. After this PR: - Products are automatically registered with eTIMS before sending invoices/vendor bills. - `View Product(s)` button now opens custom `l10n_ke_kra_product_tree` view with eTIMS-specific fields. - Product registration now properly uses the invoice's company context (`move.company_id`) ensuring products are registered to the correct company's eTIMS system in multi-company scenarios. Task-5039671 Forward-Port-Of: odoo/enterprise#93375
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` mode
Original PR description
When the user tries to perform create or copy operations on the ``hr.recruitment.stage.report`` model, a traceback appears. Steps to reproduce the error: - Install ``hr_recruitment_reports`` module with demo data - Go to Recruitment > Reporting > Hiring Velocity > switch to cohort view > click on any record > select any record > duplicate Traceback: ```py ObjectNotInPrerequisiteState cannot insert into view 'hr_recruitment_stage_report' ``` ``hr.recruitment.stage.report`` model is ``_auto=False``, meaning that no database table is created for this model. When the user attempts to create or duplicate a record of that model, It will lead to the above traceback. sentry-7024266324
This update fixes an issue where MTO backorders incorrectly displayed the delivered quantity instead of the original order total. The fix ensures that the 'Ordered' quantity accurately reflects the remaining demand for MTO products, resolving a discrepancy in reporting. This improves the accuracy of inventory tracking for MTO orders.
Original PR description
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery…
Steps To Reproduce ------------------ 1- Create an MTO product. 2- Create an SO for 10 units and confirm. 3- Deliver 5 on the first picking, validate, and create the backorder. 4- Print the delivery slip of the first (done) picking. Issue ----- 1- MTO: Ordered = 5, Delivered = 5, Remaining = 5. 2- Normal product: Ordered = 10, Delivered = 5, Remaining = 5. The ordered quantity for MTO products is wrong, it shows the delivered amount instead of the original order total. Cause ----- The delivery report calculates the "Ordered" quantity by adding what we just delivered to what is left in the backorders. I found that the code was looking for move lines in the backorders to count what is left. When I checked a backorder that is waiting for stock (like MTO), there is no reserved stock yet, so no move lines exist. Because of this, the report thought the backorder was empty and ignored the remaining quantity. Fix --- I changed the code to look at the `move_ids` instead of the `move_line_ids`. While debugging I found out that the `move_ids` record always holds the correct demand regardless of the product. opw-5112467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where users without administrative access would encounter an error when creating projects based on templates with Field Service. The fix involves ensuring proper access controls are enforced during schedule retrieval, preventing access errors for non-administrator users. This ensures consistent project creation functionality.
Original PR description
--- ## Short functional explanation of the error Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign…
---
## Short functional explanation of the error
Let's say we create a project template with field service. This will enable the start and end date of the project template and its tasks. If we assign an employee, their schedule will be retrieved to see if it matches the start and end date of the project.
If we try to create a project based on this template as an employee who's not an admin (only has rights for the project and services apps, for example), this will result in the error
This operation is allowed for the following groups:
- Employees/Administrator
- Employees/Officer: Manage all employees
Contact your administrator to request access if necessary.
Explanation: as we try to retrieve the employee schedule with an employee who doesn't have access rights to the Employee infos, it raises an access error.
## Reproduction Steps
1. As an admin, go to Projects and create a new project with a new stage and a new task. Assign an employee to this task.
2. Enable debug mode and go to the settings of the project. Under field service, check Field Service, then save.
3. Click on the small cog next to the project name and click Convert to Template.
4. Set a planned start and end date for the project and for its task. Assign a customer on the task.
5. Go to Users and select a different user than the one you assigned to the task.
6. Set this user administrator for Project and Field Service.
7. Make sure that this user also has an employee profile. Log in with this user and create a project based on this
### Expected behavior
The project is created without the entries the employee doesn't have access to
### Unexpected behavior
An access error is raised
## Origin of the issue
A sudo() was missing in the code.
__
opw-5263024This update ensures that employee contract details, specifically the work address and location, are consistently saved when a new contract version is created through the configurator. Previously, this information was sometimes lost, leading to potential data discrepancies. This change improves data accuracy for employee records.
Original PR description
When a new version is created by the configurator, we need to keep the work address and location.
This update fixes an issue where the SAFT report incorrectly assigned the supplier's receivable account to customers. The fix changes the XML data to use the customer's receivable account, ensuring accurate reporting for the SAFT document. This ensures compliance and proper financial reporting.
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 Forward-Port-Of: odoo/enterprise#99196
This update refines how website builder tests use snippets, ensuring they accurately reflect the real snippets used in the application. By avoiding matching snippets within other snippets and applying necessary processing, the tests now provide more reliable results and prevent discrepancies between the test environment and the live website.
Original PR description
Forward-Port-Of: odoo/odoo#234902
This update resolves an issue where unregistering a Nemhandel user caused the user database to no longer recognize them. The fix corrects a mismatch in exception types, ensuring that the user database is properly updated when a user is unregistered, preventing errors and maintaining accurate user tracking.
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 Forward-Port-Of: odoo/odoo#236670
This update ensures that filters applied to composite reports consistently work across all sections within those reports. Previously, filters weren't always correctly applied, leading to inconsistent report results. This change aligns with standard Odoo reporting practices, guaranteeing accurate and reliable reporting.
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#100240 Forward-Port-Of: odoo/enterprise#100148
This update corrects a technical glitch where stopping ringtone playback caused unnecessary HTTP requests. The fix resets the element's source, preventing the browser from incorrectly attempting to load a 'null' file. This ensures ringtone functionality operates smoothly and efficiently.
Original PR description
Setting the src of an element to null triggers a GET HTTP request to /null. This is not the intended behavior; we want to reset the source so that it is not linked to any file, but the browser interprets it as an attempt to load a file called "null". This commit fixes the problem by resetting the source using removeAttribute instead. [Task-5349985](https://www.odoo.com/odoo/project/5778/tasks/5349985) Forward-Port-Of: odoo/enterprise#100146
This update fixes an issue where composite reports weren't consistently applying filters to their individual sections. Now, enabling a filter on a composite report will automatically enable it on all of its components, ensuring accurate reporting results. This aligns with standard Odoo reporting practices.
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#237003 Forward-Port-Of: odoo/odoo#236893
This update addresses an issue where pressing Backspace within a blank blockquote would unexpectedly delete the entire Table of Contents. The change ensures that an empty blockquote is now converted into a standard container when Backspace is pressed, preserving the intended content and functionality. This improves the user experience and prevents data loss.
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 Forward-Port-Of: odoo/odoo#235087
This update fixes a technical issue within our Point of Sale (PoS) system that was generating warnings in the console. These warnings were related to missing widgets during order detail views. The fix adds the necessary configuration to ensure smooth operation and accurate order information display for users.
Original PR description
Steps to reproduce ------------------ 1. In PoS, make a normak order and pay it 2. Go to the "Orders", filter by "Paid" 3. Select the order of step 1 and click "Details" Observed behavior -> Warnings in the console about missing widgets. Fix --- We add those missing widgets to point_of_sale/__manifest__.py opw-5181965
This update optimizes the performance of our sales order system by adding an index to a key field. This change addresses a potential slowdown when filtering sales orders by the sales team assigned to them. By indexing this field, we're speeding up searches and improving overall system responsiveness.
Original PR description
`team_id` might be used in filters to conditionally see related `sale.order` for a specific (or set of) sales teams. If the field isn't indexed, it's a Sequential Scan on `sale_order`, which can be a large table. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237116
This update resolves an issue where multiple expense records were created when using the 'force capture' feature with Stripe. Sending the same Stripe transaction event multiple times resulted in duplicate expense entries. This fix ensures data accuracy and prevents unnecessary expense records.
Original PR description
It's possible for multiples expenses to be created when using force capture. - Setup a company in EU and do the account onboarding - create a card - simulate a test purchase with force capture - after the webhook event issuing_transaction.* is received, an expense should have been created - now send again this event to the server (from the stripe dashboard or any other way) - a second expense will be created with the same transaction_id
This update resolves an issue where pressing Alt+A in the website builder didn't correctly open the translation mode. The fix adds a necessary parameter to ensure the translation features are activated, allowing users to translate website content. This improves the usability of the website builder for multilingual sites.
Original PR description
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A…
__Before this commit:__ 1. Add a 2nd language to your site 2. Show the website homepage in the 2nd language and be outside the admin backend (no admin navbar at the top of the page) 3. Press Alt+A (the shortcut to open the builder) => The builder opens, but it is unusable. The builder options are the translation options, but the iframe is not in a translatable state. __Cause:__ Pressing Alt+A outside the admin backend just [adds `enable_editor=1` in the URL][1]. When the page is displayed in the 2nd language `data-translatable` is included in the metadata so the translation mode opens. However the iframe relies on the `edit_translations` search param being set to include the translation branding (i.e. `data-oe-translation-source-sha`) which is not the case after pressing Alt+A. __The fix:__ Add `edit_translations` when pressing Alt+A in any case. If the page is translatable, the translation mode will correclty open, otherwise it will be ignored and the edit mode will open instead. NB: By doing this, we bypass the checks in [`attemptStartTranslate`][2] therefore a user who doesn't have the proper access rights will still be able to open the translation mode but they will not be able to do anything. Using those checks would add too much complexity to the code in regards to how niche the feature is anyway. [1]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/js/content/redirect.js#L33 [2]: https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/website/static/src/client_actions/website_preview/edit_website_systray_item.js#L54 task-5125700 Forward-Port-Of: odoo/odoo#236039
This update resolves a payroll error that occurred after the introduction of versioning in the 19.0 release. The issue stemmed from outdated data files that didn't reflect the change of the 'contract' key to 'version', along with a data type error. This fix ensures 'Cadre' employee pay runs can now be processed correctly.
Original PR description
To reproduce: ============= - in FR company create employee with "Cadre" status - in Payroll -> Pay runs, create a new pay run for this employee for a given month -> Error occurs Problem: ======== after intoducing Versioning in 19, `contract` key was changed to `version` but these data files were not updated accordingly. also there was a typo in lines with `company_20id` instead of `company_id` opw-5244193
This update resolves an issue where the Facturae export XML incorrectly displayed negative values for withholding taxes. The fix ensures that withholding tax amounts are always positive, preventing rejection by the FAC (Foreign Agents Control). This improves the accuracy of Facturae submissions.
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 Forward-Port-Of: odoo/odoo#235774
This update significantly speeds up payroll processing, specifically when regenerating work entries for a large number of employees. The change reduces query execution time from 20 seconds to 2 seconds, improving overall system responsiveness and efficiency. This enhancement ensures smoother payroll operations for companies with many employees.
This update allows spreadsheet reports to group data by many2one references, specifically Lead -> Activity relationships. This addresses a request from a partner at OXP, enabling more detailed reporting on activity status linked to Leads. It's important to note that grouping by many2one_reference requires careful consideration to avoid combining data from different models.
Original PR description
This is a feedback from a partner at OXP, he wants to know the number of activities (late or not) linked to some Lead -> activities grouped by res_id. But grouping a pivot by a many2one_reference is currently not supported. This commit adds the support. Note that carelessly grouping by a many2one_reference mixes records linked to different models (same id, but different model). To avoid mixin apples and oranges, you have to either groupby model, *then* by res_id, or add the model to the domain. Task: 5102923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234142 Forward-Port-Of: odoo/odoo#227939
This update resolves an issue where shared Knowledge articles wouldn't display correctly for users accessing them through different website languages. The fix corrects a URL rewriting problem, ensuring articles are accessible regardless of the user's preferred language setting. This improves the usability of our knowledge base for all portal users.
Original PR description
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default…
## Issue: When multiple languages are enabled on the website (English + another), sharing a public Knowledge article may block portal users from accessing it For example, if the website’s default language is Spanish and the user opens the link, they are redirected to the home page and the article does not appear in the sidebar ## Cause: When accessing `/knowledge/article/...`, the `_match` route handler automatically rewrites the URL to `/en/knowledge/article/...` However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page ## Steps to reproduce: - Install Knowledge and Knowledge Website - Set Spanish and English (US) as available website languages - Set Spanish as default website language - Create an article in knowledge - Click Share and activate "Share to web" - Copy the link and open it in a private window (The article should be visible) - Log in as a Portal user - Open the link - The user is redirected to the home page and the article is missing from the sidebar opw-4916118 Forward-Port-Of: odoo/enterprise#96505
This update fixes an issue where the website builder's save button would remain disabled after canceling the language selection dialog. The change introduces a mechanism to ensure after-save handlers are executed only when necessary, improving the user experience when adding or modifying languages.
Original PR description
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these…
### [FIX] mail: clean the "beforeunload" listener in tests Some tests trigger a call to the function `Rtc.joinCall` which adds a listener on `beforeunload` event that cancels the event. Some of these tests do not trigger a later call to `Rpc.clear`, thus the listener stays registered. This could mess with other unrelated tests that check their own handlers of `beforeunload` are correct. This commit adds a cleanup on the helper used by the problematic tests. task-5138313 ### [FIX] website, html_builder: run after-save handlers if aborted Usually, running the after save handlers is not needed after the save because we are about to close or reload the builder. Thus they are not run as an optimization. But there are a few cases where they are needed: - The saving of the page failed. This case was correctly handled only when clicking on the save button or adding a module - When adding a language, but cancelling the dialog to choose the language This commit changes the save function of the save plugin, to take a async callback to determine whether the after-save handlers should run. The callback is async to be able to wait for the language choice dialog. If the callback returns `true`, then the after-save handlers are run. Steps to reproduce: - Open website builder - Open "Theme" tab - Click "Add Language" - Confirm the first dialog (about save) - Cancel the second dialog (language choice) - Bug: the save button stays disabled with the spinning wheel next to it task-5138313 Forward-Port-Of: odoo/odoo#229843
This update resolves an issue where the invoice report incorrectly displayed currency symbols and incorrect total amounts when a company's tax settings were 'tax included'. The fix ensures accurate reporting of price-included totals, improving invoice clarity and compliance.
Original PR description
When the company is "tax included" for all taxes, after signing to eTims, the invoice report: - shows the currency symbol twice for "Taxable Amount". - The xpath for 'td_subtotal' is also doubled for no reason. - The "Total" columns is always price excluded instead of being price included. task_id: 5252530 Forward-Port-Of: odoo/enterprise#100050
This update fixes an issue where the stock forecast was incorrectly displaying negative quantities due to how it was calculating demand based on completed stock moves. The fix ensures the forecast accurately reflects the actual available stock by basing calculations on the quantity of the move itself, not the original demand.
Original PR description
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form >…
### Steps to reproduce: - Create a storable product - Create a receipt for 100 units of that product - Mark as to do, set the quantity to 50 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of -50 for every date in the past ### Cause of the issue: The part of the report query relying on done moves is based on the `prodcut_uom_qty` of the move and hence on its demand. However, when the move is 'done' only its quantity should be relevant. #### Note: The same issue happen if you receive more than the demand. That is: - Mark as to do, set the quantity to 150 and validate without backorder - Go to your product form > Forecast #### > The forecast displays a quantity of 50 for every date in the past The issue did not happen prior to 17.0 because validating a move for a quantity that differs from the demand would: - in case quantity < product_uom_qty: split the move in 2: one done move where the demand matches the quantity and one cancelled move with the remaining demand. - in case quantity > product_uom_qty: the demand of the move was updated to match the quantity of the move. This has been changed in f9867a5fa572a15fb89c49c61e569427d6388cbc now, validating a move for a quantity that differs from the demand will keep the demand intact. opw-5152570 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234576
This update resolves several display issues within the mobile Kanban view for documents, specifically in the 'Recent' folder. The changes address gaps in layout and scrolling limitations, ensuring a more consistent and usable experience for users managing documents on mobile devices. This improves the overall efficiency of document access.
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#100134 Forward-Port-Of: odoo/enterprise#90647
This update resolves an issue in the 3-step manufacturing process where changing the production rule to MTSO didn't correctly trigger replenishment orders. The fix ensures that sufficient component quantities are automatically ordered when needed, maintaining accurate stock levels and preventing production delays. This improves the efficiency of the manufacturing workflow.
Original PR description
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod,…
Issue ----- In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity. Steps to reproduce ----- - Enable warehouses and multi-step routes - Set warehouse manufacturing to 3 step - Edit the 3 step production route - Change the pre-prod -> prod rule to mts else mto - Create a product "Comp" - Set a quantity of 5 in location pre-prod - Create a product "Prod" - Add a BoM with "Comp" as component - Create a MO for 10 of Prod - Confirm MO > There is a transfer stock -> pre-prod for 5 of Comp - Open the production quantity wizard, update value to 12 and confirm > The transfer still shows 5 of Comp instead of the needed 7 Cause ----- Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement` https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485 Before actually running any procurement we do https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492 Since the procurement group's method is `mts_else_mto`, when we go through https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332 we go into the `else` part and set the move's `procure_method` to mts. This means that, in the `run_procurement` method https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504 is not true, so we don't add any procurement to run. Solution ----- In `_adjust_procure_method` we update the move's rule to the MTSO one we found https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328 This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO. ----- Ticket: opw-5008871 Forward-Port-Of: odoo/odoo#235125
Accessing the chat tab in the messaging menu with many chats causes a max call stack error. This commit reverts a computed field to a getter to break the compute cycle and improve performance.
Original PR description
- Description: Signing the individual CLA for my contributions. Signed by Mahmoud Essam, esame4166@gmail.com --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where deposited amounts were incorrectly shown as 'Total Due' in customer records. A recent system update caused a miscalculation, leading to inaccurate reporting of deposits. The fix ensures deposits are now correctly displayed as deposited amounts, improving the accuracy of financial data.
Original PR description
Steps to reproduce: =================== 1. Open the customer list. 2. Select a customer and choose `Deposit money`. 3. Deposit an amount (e.g. 50) and confirm. 4. Open the customer list again. Issue: ====== The deposited amount is shown as `Total Due` instead of `Deposited`. Also the confirmation dialog for deposit showing negative amount. Cause: ====== A major refactor in order change calculation, passes the negative change value to the `depositOrder`, so the deposit was recorded as a due amount. Fix: ==== Negate the change value when adding the deposit order line so it becomes positive and is correctly shown as a deposit. Task: 5227004
This update ensures that refund orders in Point of Sale now correctly apply the same price list as the original order they were placed under. Previously, refund orders defaulted to the standard price list, leading to potential pricing discrepancies. This change improves accuracy and consistency in refund calculations.
Original PR description
Before this commit: ------------- - Refund order price list was set to the default one, while the original order used a different price list. After this commit: ------------------ - Refund order now applies the same price list as the original order. Task-5215488
This update enhances the subchannel search and list view by sorting subchannels based on their last activity date. This prioritizes the most active and relevant conversations, making it easier for users to quickly find important discussions. It improves usability and efficiency for managing communication.
Original PR description
Sub-channel search/list is currently ordered by id, but it would be more natural to order them by last interest to be able to quickly see/find those that are actually active and still relevant today at the top of the list. task-5265234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a technical issue preventing migration tests from running correctly. The change disables a date constraint during testing, allowing migration tests to advance the stock picking schedule without errors. This ensures the migration process continues to function smoothly.
Original PR description
This commit disables `_check_backdate_allowed` on stock pickings in the case of running a test. This is mainly because of the migration test in [`migrations/account/tests/test_lockdate.py`](https://github.com/odoo/upgrade/blob/master/migrations/account/tests/test_lockdate.py), which advances the lock date of all the existing companies by 15 days. Therefore, any stock picking record created in the `prepare` method of any migration test will fail, because the scheduled date is `now` by default. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a minor visual issue in the account update tax tags settings. Previously, an empty space appeared in the settings view when a user's permissions weren't correctly recognized. This change ensures the settings view is consistently displayed without any empty divisions, improving the user experience.
Original PR description
On the res config settings view, a group was applied on a button, but if the group is not respected, the button is invisible but not the setting div, leading to an empty div in the settings. Move the groups attribute from the button to the setting element, so we won't have any empty space anymore. Linked: https://github.com/odoo/enterprise/pull/84533 no-task
This update resolves an issue where the gross salary displayed in the Indian payroll salary calculator was incorrectly showing as zero. The fix ensures the gross salary is accurately calculated by retrieving default percentage rules, addressing a discrepancy in the underlying calculations. This ensures correct payroll processing for Indian company users.
Original PR description
## Issue: - When we try the salary calculator for 'IN company' the gross was showing '0'. ## Reason: - Basic salary amount is calculated based on l10n_in_basic_percentage and due to dependency of l10n_in_basic_salary_amount on l10n_in_basic_percentage and vice versa, it gives '0' percentage. ## Fix: - Fetched the default percentage from rule parameters to calculate the gross salary. Fixed the issue of gross salary displaying '0' in salary calculator for Indian Payroll. Added the default percentage in compute of basic percentage so that it fetches values from rule parameters and calculates the basic salary amount. task - 5062259
This update corrects a visual issue in the Account Online Synchronization module. Previously, only the data within the company column was hidden; now, the entire column is invisible. This ensures a cleaner and more professional user interface for users working with account synchronization.
Original PR description
The whole column needs to be invisible, not just the content of it
This update resolves a limitation that previously prevented the creation of multiple temporary directories within Odoo. By allowing multiple temporary directories, the system can now handle more complex operations, such as importing data with nested temporary files. This change ensures smoother operation and avoids potential errors.
Original PR description
Before this commit, only one temporary directory can be opened concurrently, which prevents for example nested temporary directories. This commit removes this limitation by adapting the __file_open_tmp_paths variable, which is now an array where we store opened temporary folders. It also adds tests about file_open(temporary_directory) methods.
This update resolves an error that occurred when users tried to replace work entries within a payslip using the Gantt view. The issue stemmed from incorrect data being passed to the view, causing 'Missing record' or 'Contract out of range' errors. This fix ensures the correct employee ID is used, improving the reliability of the work entry scheduling process.
Original PR description
**Steps to reproduce:** - Install the hr_payroll module. - Open the form view of an employee with a running contract and click on the Payslip smart button. - Create or open an existing payslip, then open the Work Entries from smart button. - Click on any day cell and then click the Quick Replace button. **Issue:** Clicking the Quick Replace button (next to Set) triggers an error, 'Missing record' or 'Contract out of range.' **Cause:** The issue occurs due to an incorrect context being passed in the Gantt view (https://github.com/odoo/odoo/pull/223409). The view incorrectly passes the payslip ID instead of the employee ID. **Fix:** This PR updates the context to ensure the correct employee ID is passed to the Gantt view. task-5219487
This update corrects a minor issue where Odoo would display an error if a required field was hidden. The change ensures that Odoo correctly handles invisible fields, preventing unexpected errors and improving user experience. This ensures data entry processes run smoothly.
Original PR description
When a required select is invisible, you may get an error saying the a required field is not set. So like for other type of fields, we check the visibility of the field.
This update corrects a bug in how purchase orders with warnings are displayed. Previously, POs without any activities were shown, regardless of whether a warning was present. This change ensures that POs with warnings are correctly identified and displayed, restoring the expected behavior from previous versions.
Original PR description
Steps To Reproduce ------------------ 1- To purchase orders 2- Create random purchase orders (with activity and without and with warning) 3- Select the Warning Filter Issue ----- 1- Only POs with no…
Steps To Reproduce
------------------
1- To purchase orders
2- Create random purchase orders (with activity and without and with warning)
3- Select the Warning Filter
Issue
-----
1- Only POs with no activities show on the list.
2- The behavior in versions previous to 18.3 works perfectly fine, showing only POs with warnings.
Cause
-----
The issue is caused by this commit: 92301a5b300dec1ddfca44dc35318b83d67c56fa.
The search logic for the activity_exception_decoration field was changed to refuse negative operators (`!=`):
https://github.com/odoo/odoo/blob/92301a5b300dec1ddfca44dc35318b83d67c56fa/addons/mail/models/mail_activity_mixin.py#L118-L121
This forces the ORM to invert the filter:
https://github.com/odoo/odoo/blob/9a8350cb476af73d6bf4eea75344963eac1c7831/odoo/orm/domains.py#L873-L880
For this case, this transforms the intended query:
`Exists(activity_exception_decoration != False)` ("Has Warning")
Into the inverted query:
`NOT Exists(activity_exception_decoration == False)` ("Does NOT have a Normal activity")
This incorrectly hides records that have both warning and normal activities, and incorrectly shows records with no activities at all.
opw-5177277
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236732This update resolves an issue where timesheet entries linked to reversed invoices were previously uneditable. Now, after reversing an invoice, users can correctly modify timesheet entries associated with that invoice through the recorded hours feature, ensuring accurate time tracking and reporting. This improves the reliability of financial data.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#236601 Forward-Port-Of: odoo/odoo#201921
This update fixes an issue where tax return amounts were incorrectly calculated for section reports, specifically in the LU tax return. The change ensures the correct return periodicity is used by retrieving the return type from the section source, resolving a discrepancy between the main report and the section report.
Original PR description
We have some reports with sections, like l10n_lu generic tax return.
Since account.return are born, when submitting the lu tax return, the periodicity is wrongly
computed, because of the self in `_init_options_return_periodicity` is the section report, not the main,
but the account.return.type is set with report_id = main report
Step to reproduce:
With a LU company:
1. Create a journal entry for a previous period
2. Submit the tax return for the same period
3. The amount shown is the amount of the current month
Solution: use options['sections_source_id'] to fetch the return_type instead of self.return_type_ids
opw-5163352
Forward-Port-Of: odoo/enterprise#100063This update fixes an issue where the price displayed in Point of Sale (PoS) was incorrect when using non-groupable units of measure. The fix ensures that the correct price unit is applied during order settlement, leading to accurate pricing calculations for products with these specific UoMs. This improves the reliability of PoS transactions.
Original PR description
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If…
Steps to reproduce ------------------ 1. Create a product with a UoM that is non groupable in PoS 2. Make a sale order with that product having a UoM that is based on the UoM of the first steps. If the UoM in the first step was Kg for intsance, use Gram (g) here. 3. Confirm the order, and settle it in PoS. Notice that the price of that order in PoS is not correct. Why it's happening ------------------ When settling the PoS order, we first convert the sale_order's line UoM (g) to the original product UoM (kg), and we update the quantity accordingly (in this example by dividing by 1000). https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96 So this step updates both the qty and the unit_price. https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161 However, when the UoM is not groupable, we split the lines by taking into consideration the updated qty, but we still use the old price_unit, which creates an inconsitency and wrong calculations. The fix ------- When splitting the lines, we're just supposed to change the qty per line to max 1, but we're not supposed to change the price per unit for this qty. We now use the updated `price_unit` to have a correct math. opw-5232571 Forward-Port-Of: odoo/odoo#237246 Forward-Port-Of: odoo/odoo#236008
This update resolves an issue where archived loyalty cards were still accessible and usable within the system. The fix corrects a filtering error that prevented inactive cards from appearing in search results. Additionally, it prevents points from being incorrectly applied to archived loyalty cards, ensuring accurate reward management.
Original PR description
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a…
## Issue 1: In this issue, active/inactive filter is not working correctly. #### To reproduce: 1- Install `Sale` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Create a `Loyalty Card` for the program 5- Archive the card 6- In search, click on `inactive` filter As you see, you can't find the archived card. ### Cause: This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`. ## Issue 2: In this bug, earned points on archived loyalty can be used to claim rewards. #### To reproduce: 1- Install `Sale` and `Ecommerce` 2- Active `Promotions, Loyalty & Gift Card` 3- In `Discount & Loyalty` create a loyalty program 4- Add a rule to grant 10 points per order 5- Apply a reward in exchange of 10 points 6- Create a `Loyalty Card` for the admin with 0 points. 7- In Ecommerce, add a product to your cart 8- Remove the product from the cart 9- Archive the loyalty card created for the admin 10- In Ecommerce, add another product to cart 11- As you see, you still can use the loyalty card ### Cause: When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards. To prevent this, we can unlink points from draft sale order when the card is archived. opw-5166696 Forward-Port-Of: odoo/odoo#233645
This update resolves a bug that prevented users from correctly sorting the Time Off Ledger report. The issue stemmed from a default sorting rule that conflicted with user-specified sorting directions. Now, users can reliably sort the report in both ascending and descending order, ensuring accurate reporting.
Original PR description
Version - 19.0 ## Issue: Sorting the Date column in the Time Off Ledger triggers a traceback when attempting to sort in ascending order. ## Steps to reproduce: - Open the Attendances app - Navigate…
Version - 19.0 ## Issue: Sorting the Date column in the Time Off Ledger triggers a traceback when attempting to sort in ascending order. ## Steps to reproduce: - Open the Attendances app - Navigate to Time Off Ledger report - Click on dates column for sorting --> you get a traceback ## Cause: The code always appends `' desc'` to the order clause to enforce a default descending sort. When the UI already provides a direction (e.g. `date:month ASC`), this results in an invalid combined order such as `date:month ASC desc`, raising: `ValueError: Invalid order 'date: month ASC desc' for _read_group().` ## Fix: Add a check to avoid appending `' desc'` when the order string already contains `asc` or `desc`. ## Impact: Sorting the Date column no longer crashes. Users can now sort the report correctly in both ascending and descending order, with descending remaining the default. task-5331052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures product prices displayed in the self-order POS accurately reflect the prices calculated using the active pricelist. Previously, prices were inconsistent, but now the system automatically applies the correct pricelist, even when presets are used without a specific pricelist assigned.
Original PR description
### before this commit: - Product cards displayed the product’s sale price instead of the price computed from the applied pricelist, even though the order total reflected the correct discounted amount. - When a preset was enabled, the pricelist was applied only if it is explicitly set on the preset. ### after this commit: - Product cards now show prices according to the active pricelist rules. - When the preset is enabled without a pricelist, the default POS pricelist is applied automatically. task-5236959
This update fixes a missing translation file for the Finnish reports module. It also removes translation from a specific sales report, ensuring consistent and accurate reporting in Finnish. This improves the usability of Odoo Enterprise for Finnish-speaking users.
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate report column names in the PO files as we have official translation for it. This commit also disables the translation on the TXT EC sales report. no task id [1]: https://github.com/odoo/enterprise/commit/4887ed53d3a22fdcd766ab0ae77da7cb0498e5a3 Forward-Port-Of: odoo/enterprise#100308 Forward-Port-Of: odoo/enterprise#99887
This update addresses a memory issue that occurred during the v19 upgrade mock crawl when retrieving product information. The fix utilizes a controlled lookup instead of a large relational prefetch, preventing the 'MemoryError' and ensuring smoother operation. This resolves a potential crash and improves stability.
Original PR description
During v19 upgrade mock crawl, accessing `source.move_ids.product_id` triggered a huge relational prefetch, crashing with: ```py File…
During v19 upgrade mock crawl, accessing `source.move_ids.product_id` triggered a huge relational prefetch, crashing with:
```py
File "/home/odoo/src/odoo/19.0/addons/delivery/models/delivery_carrier.py", line 209, in _match_must_have_tags
products = source.move_ids.product_id
File "/home/odoo/src/odoo/19.0/odoo/orm/fields_relational.py", line 75, in __get__
super().__get__(remaining, owner)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1692, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3769, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3809, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3930, in _fetch_query
field._insert_cache(fetched, values)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1599, in _insert_cache
collections.deque(map(field_cache.setdefault, records._ids, values), maxlen=0)
MemoryError
```
Full traceback: https://pad.odoo.com/p/aTIGHsnDMrfMENfmU5TK
Use a controlled lookup instead.
opw-5223443
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update automatically activates the EC Sales List report menu item for Odoo Enterprise users in several European countries (Bulgaria, Cyprus, Czech Republic, Latvia, Malta, Poland, Romania). Previously, users in these regions had to manually enable the report, streamlining the reporting process and improving usability.
Original PR description
In this PR: - Added XML records to set the EC Sales List report menu item as active for some EU countries that previously required manual activation. Task-4885725 Forward-Port-Of: odoo/enterprise#93939
This update addresses a technical issue identified by Odoo's automated testing system (runbot). The fix ensures that localization tours within the Point of Sale module function correctly for different regions, improving the user experience for international customers. This resolves a previous bug that prevented proper localization setup.
Original PR description
Fix runbot issue runbot-233183 Forward-Port-Of: odoo/enterprise#100069 Forward-Port-Of: odoo/enterprise#99370
This update resolves issues with how the Hoot mock server handles 'blob:' URLs and nested data streams within unit tests. It now correctly mocks these URLs and properly parses data, ensuring more reliable test results and improved functionality for attachments.
Original PR description
See commit messages for details --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236395 Forward-Port-Of: odoo/odoo#234558
This update corrects a missed step in the Finnish translation process, ensuring the POT file is properly maintained. It also translates a key business term, improving the accuracy and usability of the Odoo application for Finnish users. This ensures compliance with local regulations and a better user experience.
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate the Business ID term for the correct one. no task id [1]: https://github.com/odoo/odoo/commit/7ef02a48f3c93cb8aca9337a27c3c87636fb03a0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237098 Forward-Port-Of: odoo/odoo#236469
This update fixes an issue where users were incorrectly changing product details on combo item lines. To address abuse of the system, a temporary workaround has been implemented requiring users to hide product fields before editing the description. This ensures data integrity within combo orders.
Original PR description
This was initially allowed so that the user could edit the description on combo item lines (since both the product and description fields are displayed in a single column). However, users seem to abuse this (see https://github.com/odoo/odoo/pull/234090). For information, the description can still be edited, but to do so, the user must first hide the `Product` and `Product variant` columns (which can be shown again after making the necessary changes). Forward-Port-Of: odoo/odoo#237148 Forward-Port-Of: odoo/odoo#235547
This update resolves an instability issue within the Point of Sale (PoS) localization tour. The change removes a problematic closure step, which previously caused frequent failures due to the PoS's complex setup. This improves tour performance and reliability.
Original PR description
backport of : https://github.com/odoo/odoo/pull/231884 Remove the closing of the PoS in the tour as it is really unstable and fail a lot. It's mostly due to the fact that the PoS take a long time to close with a lost of modules installed. This will also make the tour faster. runbot-233183 Forward-Port-Of: odoo/odoo#236747 Forward-Port-Of: odoo/odoo#234310
This update resolves an issue where the base_import module would fail when users lacked access to the underlying data definition. The fix now includes checks for field group restrictions, preventing crashes and ensuring smoother data import processes. A new test case has been added to verify this improved behavior.
Original PR description
…ible https://github.com/odoo/odoo/pull/236037 ignores the properties field if we don't have access to the definition model at all. However, we should also check field groups to avoid crashing if the user cannot access the definition field because of group restrictions. Forward-Port-Of: odoo/odoo#237166 Forward-Port-Of: odoo/odoo#236912
This update resolves a bug where setting the background image width to 0px in the website builder's 'Repeat pattern' mode caused the background to disappear. The fix ensures that the input fields reset correctly to the default 'auto' size, maintaining proper background image display.
Original PR description
__Current behavior before commit:__ In "Repeat pattern" mode, users can set the background image's width and height to 0px, which doesn't make sense. Additionally, clearing these input fields resets their values to 0px instead of reverting them to `auto`. __Description of the fix:__ Make it possible to clear those fields by setting their default value to `null` and set the minimum value to 1 to prevent the image from disappearing. __Steps to reproduce:__ 1. On the website, drop a `s_cover` snippet 2. Set Background > Image > Position to "Repeat pattern" 3. Delete the content of the "Width" input => The background disappears. task-5094899 Forward-Port-Of: odoo/odoo#231216
This update resolves a problem where credit notes weren't correctly validated by the Spanish tax authority (FACe). The fix ensures the XML data used for credit notes adheres to Spanish regulations, improving compliance. Additionally, the reversal wizard has been streamlined for better usability.
Original PR description
In cases of credit notes, the xml would not be validated by the FACe. This was caused by the field 'ReasonDescription', which can only be one of the proposed field. We used to provide it in English when the available reasons are only in Spanish. Also fixed CorrectionMethodDescription. See https://www.facturae.gob.es/formato/Paginas/version-3-2.aspx for more documentation. ticket-5184181 Took the opportunity to improve the reversal wizard : In the reversal wizard, two fields 'Reason' would be displayed. Only kept the mandatory one and used it in place of the non-mandatory one. Forward-Port-Of: odoo/odoo#236684
This update resolves an issue that prevented fiscal receipts from generating correctly when multiple payment methods were used in a POS order. The fix ensures unique identification of payment methods, eliminating a 'duplicate key' error that was causing failures.
Original PR description
When multiple payment methods are used in a POS order, the fiscal receipt generation fails with "Got duplicate key in t-foreach: 0" error. This occurs because all payment methods have the same default it_payment_index value (1), causing duplicate keys in the Owl template's t-foreach loop. This fix uses the payment's database ID (payment.id) as the unique key in the template loop instead of relying on the payment method's it_payment_index value.
This update ensures return deadlines are accurately calculated across all Odoo databases, particularly those migrated before a previous upgrade. It resolves an issue where returns marked as 'completed' without a deadline date would cause errors, now defaulting them to a deadline of today to maintain data consistency.
Original PR description
[FIX] account_reports: returns: recomputed date_deadline when is_completed is set to False To align it with the current deadline delay configured on the return type, and keep data consistent. Also,…
[FIX] account_reports: returns: recomputed date_deadline when is_completed is set to False To align it with the current deadline delay configured on the return type, and keep data consistent. Also, databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed with no value set for the deadline. With this, we ensure unmarking them as completed will grant them one. opw-5259168 ==================================================================== [FIX] account_reports: returns: avoid error when computing days_to_deadline for migrated dbs Databases migrated before https://github.com/odoo/upgrade/pull/8841 could contain returns marked as completed, but without any date_deadline. On such a db, if you open the list of returns, then remove the "to do" filter, you get an error, because _compute_days_to_deadline tries to substract today from None. This commit just makes the computation more resilient, and arbitrarily chooses that a return without deadline is due today. opw-5259168
This update fixes a potential issue where rental returns could exceed the quantity picked up. Previously, users could return more products than were initially taken, leading to inaccurate inventory counts. This change ensures that returned quantities never exceed the picked-up quantities, improving rental accuracy and reporting.
Original PR description
## Versions 17.0+ ## Issue It is possible to return more products than what has been picked in Rental. ## Steps to reproduce - Create a service product available for rent; - Create a rental SO for any partner: - Add 5 units of the created service; - Confirm the SO; - Pickup 5; - Return 4; - Return 4; - Check the SOL containing 5 delivered products and 8 returned products. opw-5259727 Forward-Port-Of: odoo/enterprise#100303 Forward-Port-Of: odoo/enterprise#100015