Daily updates from Odoo
Friday, April 17, 2026
47 changes · saas-19.1
Enhancements to existing features
This update simplifies the creation of Spanish tax reports (303 and 347) for users. Specifically, the 'exonerated from 390' field is now automatically displayed on the print wizard for recent periods, eliminating manual setup. Additionally, the annual report 347 now groups data by move type and date for enhanced audit capabilities.
Original PR description
In this PR: - In tax report 303, the 'exonerated from 390' boolean field is now visible on the print BOE wizard , when period is either last month or last quarter so that user does not have to enable it manually on the AEAT page. - In the annual tax report 347, when a user clicks to audit the operations of the entity, a new group by is added in context to group the reports by move type and date(quarter). task-5863744 Forward-Port-Of: odoo/enterprise#113644 Forward-Port-Of: odoo/enterprise#108057
Resolved issues and error corrections
This update corrects an issue where account searches on invoices only worked when searching by name, not by code. Now, account searches on invoices function correctly regardless of whether the user searches by name or code, ensuring accurate results. Additionally, a 'Search more...' option is always visible for Account searches.
Original PR description
Currently, on invoices, the account_id many2one field overrides `name_search` to limit search results based on account types, but that is applied only if the account is searched by name. If the account is searched by code, all the accounts appear in search results which is not intended. This commit fixes that issue. task-6075233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257850
This update fixes an issue where custom snippets created in Website Edit Mode were only available as inner content. Now, snippets can be used both as blocks and inner content, aligning with previous versions. This improves flexibility for users creating website content.
Original PR description
Steps to reproduce: 1. Go to Website > Edit mode. 2. Drag and drop a `Map` from `Inner Content` snippets. 3. Save it as a custom snippet. Current behavior: - The custom snippet is saved only as inner content and does not appear as a block in custom snippets. Expected behavior: - The snippet should be available both as a block and as inner content, consistent with behavior in `saas-18.3`. Issue: - Custom inner content snippets were systematically extracted from `snippet_custom`. As a result, snippets that can serve both purposes were only kept as inner content, preventing their usage as blocks. Solution: - Update the logic to: 1. Keep dual-purpose snippets in `snippet_custom` (block usage). 2. Also add them to `snippet_custom_content` (inner content usage). 3. Remove only inner-only snippets from the block category to avoid display issues. task-6064917 Forward-Port-Of: odoo/odoo#259452 Forward-Port-Of: odoo/odoo#256777
This update fixes a bug that prevented users from using keyboard shortcuts (Tab, Enter, Shift+Tab) to select values within selection fields in list views. Previously, the system prioritized certain key presses, blocking the intended shortcut functionality. Now, users can seamlessly navigate and select values using their keyboard.
Original PR description
Steps: - Open any editable list view (for example sub-list view in sales) - Either it has a selection field or you add it via studio - With two values (for example "true" and "false") - Add a record to your list view - Try to edit the selection field - Popover is opened - You can select any value with a mouse click - You can navigate through values with arrows - You can't select values with `Enter` and `Tab` So list cell in edit mode has a function for all theses hotkeys: - `tab` - `shift+tab` - `enter` - `escape` Because `ListRenderer.onCellKeydown` is called before `hotkeyService.onKeyDown`, if any hotkeys is handled in cell edit mode it will be prevented and the hotkeyService will not propagate it to `select_menu`. That's why arrows are working, because there are not listed in cell edit mode keys. opw-6025476 Forward-Port-Of: odoo/odoo#255029
This update fixes an issue where individual POS e-invoices were incorrectly showing a zero Total Amount Payable. The change ensures that the payable amount accurately reflects the total e-document amount, as required by the MyInvois tax officer and helpdesk. This prevents discrepancies in the data sent to MyInvois.
Original PR description
For individual POS e-invoices, the PrePayment Amount was mapped to the payment linked to the invoice. This incorrectly decreased the Total Amount Payable to 0, since POS orders are already paid at the counter. MyInvois tax officer and helpdesk requires that the Total Amount Payable (cbc:PayableAmount) to reflect the total amount of the issued e-document, regardless of prior payments. This commit forces the PaidAmount to 0 for individual POS e-invoices, ensuring the PayableAmount correctly matches the TaxInclusiveAmount as expected by the MyInvois API. task-6057187 Forward-Port-Of: odoo/odoo#259339 Forward-Port-Of: odoo/odoo#258824
This update fixes an issue where users couldn't sort sale orders by delivery date. A recent change made the delivery date field un-sortable. This fix adds the 'promised delivery' date back to the list view, allowing users to sort sale orders effectively based on their promised delivery times.
Original PR description
Version: --- 19.1+ Issue: --- it's not possible to sort sale order list using `delivery date` anymore. After 30b895e3bd93ab3f0c0a86c3fcfd0fc0c3b6fb89, a `delivery_field` field is introduced, and `commitment_date`'s string is renamed to `promised delivery`. The new `delivery_date` is a compute field, hence it isn't sortable. The propostion here is to add `commitment_date` to the list view, in case users want to sort the list using `Promised delivery date`. opw-6112037
This update fixes a problem where the Point of Sale system was incorrectly trying to access printer settings. The fix ensures the system correctly identifies and uses available printers, preventing potential errors during sales transactions. This improves the reliability of the POS functionality.
Original PR description
We were looping over non existing `config.printer_ids`. It's either `config.receipt_printer_ids` or `config.preparation_printer_ids`. We now loop over a set containing values of both.
This update simplifies the process of reloading your chart of accounts. Previously, users received a confusing error message, but now a clear warning directs them to the necessary localization settings within the Odoo Apps menu. This change improves user experience and reduces potential frustration.
Original PR description
Previously, when new taxes with new tax tags were introduced, reloading the chart of accounts would raise a generic UserError suggesting to update the localization app. This could be confusing for users, as it did not indicate which app needed to be updated. With this commit, the UserError is replaced by a RedirectWarning that guides users directly to the Apps menu with the relevant localization modules, making the resolution clearer and more user-friendly. Forward-Port-Of: odoo/odoo#259539 Forward-Port-Of: odoo/odoo#257515
This update resolves issues preventing large actions (like printing receipts) from working correctly on the Windows IoT version of Odoo. Specifically, the Nginx configuration has been adjusted to handle larger file uploads and ensure compatibility with Virtual IoT environments, addressing previous LNA functionality problems.
Original PR description
Built installer for testing: https://drive.google.com/file/d/1wF7MCiQox3nAsW9CXg75wsV_Y5fF-5Rw/view?usp=sharing This commit makes the following changes that bring the Windows IoT nginx config in line with the Raspberry Pi version: - The `client_max_body_size` is set to 10MB. This prevents a 413 error from being received when sending large actions to the IoT (e.g. printing a large receipt). - It now listens on regular HTTP as well as HTTPS. This fixes LNA not working with Virtual IoT. opw-6106765, opw-6108700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259635
This update fixes an issue where the unit cost of products was incorrectly calculated when considering stock held in internal locations like subcontracting warehouses. The change ensures accurate valuation by properly accounting for all relevant inventory locations, leading to more reliable inventory reporting.
Original PR description
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can…
This commit addresses two valuation issues with respect to transit/internal locations without specific warehouses (such as the subcontracting location): 1. The `avg_cost` (unit cost) of products can drastically differ from its expected value since the valued quantity considered in the product total value is not necessarily the `qty_available` but the avg cost is computed as such: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L272-L273 2. The `value` of stock.quants is unexpectedly impacted by the quantity present these other locations for the same reasons: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/stock_quant.py#L57-L65 ### Steps to reproduce: - In the settings enable Multi-Steps Routes - Create a storable with an avco perpetual valuation with a cost of 5$ - Click the `On hand` smart button > Update Quantity - Put 1 unit in WH/Stock and 2 units in Subcontracting - Go to Inventory > Reporting > Stock #### > The unit cost of your product is 15$ instead of 5$ - Click on locations on the line and remove the `internal` filter #### > The value in WH/Stock is 15$ instead of 5$ and the one in Subcontracting is 30$ instead of 10$ ### Cause of the issue: The total value of a product is computed with an additional valuation context in order to consider valuated locations and dates properly: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L231-L247 https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 However, the `avg_cost` is computed by dividing this total value by the `qty_available` with apriori completely different context: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L271-L273 In teh present use case, the `qty_available` outside of the valuation context is 1, while the valuated quantity was 3 (as it did consider all of the internal valuated locations (e.g. Subcontracting)) because of these lines: https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L202-L205 https://github.com/odoo/odoo/blob/93095e1e9507fde18aefe91aac8c9cb53cadc2f3/addons/stock_account/models/product.py#L361-L363 ### Additional issue: The variable definition in this loop is incorrect: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L251-L262 Since `prodcuts` is defined just above: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L202-L205 and is expected to be used as such unaltered: https://github.com/odoo/odoo/blob/1cf08a339c4b46d23c58beecb563b3438e64f0e3/addons/stock_account/models/product.py#L264-L266 In particular, the current variable declaration lead only to a valid process of the last `cost_method` group. As this variable is only introduced for the purpose of the loop computation we rename it. opw-5959720 opw-5883980 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257103
This update resolves an issue where the checkout process became unresponsive when using the l10n_br_avatax_sale module with CPF identification. The previous implementation unnecessarily called external tax APIs, leading to errors and a broken confirmation step. This fix removes the problematic API call, ensuring a smoother checkout experience.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/odoo#259522 Forward-Port-Of: odoo/odoo#256692
This update resolves a technical error that prevented users from selecting a store when the store's address information (city or street) was incomplete. The fix ensures the system correctly handles missing address details, improving the reliability of the Click and Collect feature. This prevents a frustrating user experience and ensures accurate store selection.
Original PR description
Issue: --- An owl error is raised in select store if the store's company location lacks city or street. Steps to reproduce: 1- Enable Click and Collect. 2- In pickup locations, set a company with an address with empty street or city. 3- Go to the shop. 4- Enable debug mode. 5- Select store. An owl error is raised due to not city and street not being string. opw-6050137 Forward-Port-Of: odoo/odoo#259397 Forward-Port-Of: odoo/odoo#259164
This update fixes an issue where offline orders were incorrectly having their payment dates automatically updated to the current date when brought into the POS. This ensures that the recorded payment date for saved orders remains accurate, improving the reliability of sales reporting and order management. This change was made to maintain data integrity.
Original PR description
Before this commit, saved orders that were captured offline, would have their payment_date overridden to the current date when they were loaded in the POS. opw-6117966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259114
This update resolves a technical problem where the website's cookie bar incorrectly persisted a value, leading to potential issues with website performance and error messages. The fix prevents the cookie bar from setting a default value when it's closed without user interaction, ensuring a smoother user experience.
Original PR description
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup`…
Steps to reproduce: - Set the cookies bar - Do not accept nor reject it - On the website homepage, click on the search button => Check the cookies: website_cookies_bar=true is set. `Popup` initializes `cookieValue` to `true` and writes it in `onHideModal()`. If the cookies bar is closed before any explicit consent choice, it can therefore recreate the legacy invalid value `website_cookies_bar=true`. This happens because the search button uses `data-bs-toggle="modal"`, which is controlled by Bootstrap: if it is opened while another bootstrap modal is already open on the page, the latter is hidden. This in turn calls the popup interaction's `onHideModal()`, which sets `website_cookies_bar=true` as `cookieValue` hasn't been changed. That value is later treated as invalid and cleared repeatedly during website rendering, which can accumulate duplicate `Set-Cookie` headers in the same response and lead to `upstream sent too big header` behind nginx. Avoid persisting that legacy value by returning early from `CookiesBar.onHideModal()` while `cookieValue` is still the inherited default `true`. opw-6037573 Forward-Port-Of: odoo/odoo#258938
A technical issue in the Luxembourg tax reporting module (l10n_lu) was causing negative values to appear for certain tax lines. This update corrects a formula change, ensuring that credited amounts are displayed accurately as positive values in the tax report. This ensures correct tax reporting for Luxembourg businesses.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/odoo#259388
This update corrects a problem where electronic invoices (FatturaPA) generated with units of measure containing special characters (like m² or m³) failed validation. The fix ensures these units are properly formatted before being included in the XML, guaranteeing compliance with Italian tax regulations and preventing invoice rejection.
Original PR description
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails…
### Issue before this commit: When generating the electronic invoice XML (FatturaPA) with units of measure containing non-standard Unicode characters (e.g. m², m³), the resulting XML fails validation, as these characters are not accepted by the SdI format. ### Steps to reproduce the issue: 1. Download Italian loc + electronic invoicing 2. Activate UoM option in settings 3. Set a product UoM in any unit that has an apex/power of (ex. m2, m3) 4. Invoice this product 5. Create the XML for SdI 6. Check format with Fex > apex is not recognised as a valid character ### Cause of the issue: The UoM name is exported as-is into the XML. Non-standard Unicode characters are preserved during formatting and are not compatible with the allowed character set defined by the FatturaPA specifications. ### Reason to introduce the fix: Ensure that units of measure are normalized into a compatible representation before being included in the XML, so that the generated file complies with SdI validation rules. opw-6075119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259076 Forward-Port-Of: odoo/odoo#257012
This update corrects a bug in the Point of Sale system's tax calculation process. Previously, when a fiscal position lacked tax information, an empty tax list was returned. This change ensures that tax calculations align with the underlying Python logic, improving accuracy and reliability of sales transactions. The fix addresses an internal issue identified in opw-6126210.
Original PR description
When a fiscal position has no tax_ids, the JS implementation was unconditionally returning an empty array. The Python map_tax method only removes all taxes when the taxes themselves carry fiscal_position_ids (the tax-units pattern); otherwise it passes the original taxes through. opw-6126210 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259555
This update resolves an issue where mobile self-orders were incorrectly appearing in order lists for different Point of Sale (PoS) configurations within a company. The fix ensures that mobile self-orders are only displayed within their originating PoS configuration, improving order management and preventing confusion. This change enhances the accuracy of order data across our system.
Original PR description
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back,…
Steps to reproduce ------------------ 1. Have two PoS configs in the same company (e.g. Bar with QR+ordering and Restaurant) 2. Open Bar, go to its self-order mobile menu, place an order 3. Go back, open Restaurant, click on Orders tab -> The Bar's self-order shows up in the Restaurant's order list. What's happening ---------------- In the `getServerOrders` override added by 6782262a4d96, the domain used to fetch tableless self-orders filters by `company_id` instead of `config_id`, so it pulls in self-orders from ALL configs in the company. But we only want self-orders that are of type "kiosk" to be shown in other configs, while the ones of type "mobile" should only be shown in the config they belong too (or a trusted config). The fix ------- We adjust the domain by stop fetching company-wise mobile orders in other configs, we only keep fetching the kiosk ones. Note that mobile ordres belonging to the current config (or trusted ones) are still fetches in the main `getServerOrders` method. opw-6068187 Forward-Port-Of: odoo/odoo#258712
This update fixes a problem where users without attendance officer or administrator permissions couldn't access overtime attendance records. The fix adds specific user groups to the 'Overtime Details' section, granting necessary read access and ensuring proper functionality for all users.
Original PR description
Steps to Reproduce: - Log in as user which has no access of attendance - Try to open attendance record with overtime Issue: - As users below attendance officer and hr administrator does not have access to rule_ids Fix: - Added groups on 'Overtime Details' section as other user does not have access to read. task-5886324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the Invoice Journal field wasn't displayed correctly when a user changed the invoice's company and only one suitable journal was available. Previously, this prevented users from updating the journal, leading to an error. Now, the Journal field will always be displayed if it differs from the single suitable journal, allowing for accurate updates.
Original PR description
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases,…
…e_journal_ids and it differs from the current journal_id This resolves an issue that occurs when a user changes the invoice’s company and only one suitable_journal_ids is available. In such cases, the journal_id is not displayed, preventing the user from updating it. As a result, the following error appears: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Description of the issue/feature this PR addresses: The Invoice Journal is not displayed when the Invoice’s Company is changed, preventing the user from updating it. This leads to the error: "Invoice belongs to company 'A' while 'Journal' (journal_id: 'Journal of Another Company') belongs to another company." Current behavior before PR: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field is hidden, even if the current Journal value does not match the suitable one. This prevents the user from updating the Journal. Desired behavior after PR is merged: When there is only one suitable Journal for the Invoice after changing the Company, the Journal field should be displayed if it differs from the only suitable Journal, allowing the user to update it. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259573
This update resolves an issue preventing users from adding TDS entries when working within branch companies in India. The fix corrects a currency access error caused by referencing the parent company instead of the branch company, ensuring proper access rights and functionality.
Original PR description
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator**…
**Steps to reproduce:** * Install the **l10n_in** module. * Create a **branch company** under an Indian company. * Switch to the branch company only. * Create a user with **Accounting Administrator** access (and bank validation rights) and also give permission of this branch company. * Login from this user . * Create and confirm a vendor bill in the branch company. * Click **TDS Entry** and select any TDS section. **Observed behavior:** * An **AccessError** is raised when selecting the TDS section. **Cause:** * In `_compute_amount` (wizard), currency is taken from `tax_id.company_id`. * For branch setups, taxes (and related accounts) belong to the **parent company**, so `tax_id.company_id` points to the parent. * The user operating in the branch company does not have access to the parent company, triggering an access error. **Fix:** * Use the wizard’s `company_id` instead of `tax_id.company_id` when determining currency. * The wizard `company_id` is correctly computed based on the active company, ensuring proper access rights. **Note:** * Regression test is not feasible due to ORM cache behavior: * In tests, `mock` environments share a transaction-level cache. * `compute_sudo=True` fields populate cache with superuser access. * By the time `_compute_amount` runs, values are already cached. * No database fetch occurs, so record rules are not evaluated and the AccessError cannot be reproduced. opw-6095312 Forward-Port-Of: odoo/odoo#259091
This update fixes a potential issue where Odoo would attempt to run a monitoring function during the Python interpreter's shutdown process. The interpreter clears resources, and this function would try to access data that no longer exists, causing an error. This change ensures the monitoring function doesn't run at shutdown, improving stability.
Original PR description
Odoo registers a callback function to track how much time is spent in garbage collection. But while the Python interpreter is shutting down and clearing out global modules and variables to free up memory and the Garbage Collector triggers one last time, the callback function `_timing_gc_callback` tries to run, but the function it depends on (like time.thread_time_ns) have already been set to None by the interpreter. Forward-Port-Of: odoo/odoo#259328
This update ensures payments to Viva.com are consistently confirmed, even if the connection temporarily drops. The system now automatically retries payment confirmations silently, preventing payments from being incorrectly marked as failed and ensuring accurate accounting. A notification alerts the user to connectivity issues.
Original PR description
When a payment was sent to Viva.com and the connection dropped before receiving confirmation, the polling loop in waitForPaymentConfirmation would stop because _handleOdooConnectionFailure set the payment status to "retry" and rejected the promise. This left the payment debited on Viva's side but unconfirmed in the POS. Now the polling uses a direct silent ORM call instead of _call_viva_com to avoid triggering _handleOdooConnectionFailure. On connection failure, the poll silently retries on the next interval until a definitive success/failure response is received. A one-time warning notification informs the user that connectivity was lost. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259564
This update fixes an issue where images were repeatedly reloaded every time a user navigated between views in the employee management system. The fix prevents unnecessary image retrieval by caching images when they relate to different records. This results in faster page loading and a smoother user experience.
Original PR description
Steps to reproduce ================== - Login as Demo - Go to Employees - Open a record - Go back to the kanban view -> Every image is retrieved again Cause of the issue ================== When loading an image, we add a unique parameter with the write_date of the record. We cannot use that for images on another record. Since we have no way of knowing when the image was changed, we used the timestamp when instanciating the ImageField. The downside is that every time we navigate to a view, every image is reloaded Solution ======== When the image is on another model, we don't pass the unique parameter. This means the image will be cached. A page refresh will be needed if the image has been updated in the current browsing session. opw-6070176 Forward-Port-Of: odoo/odoo#258943
This update fixes a recent issue where generated PDF invoices from Peppol invoices were displaying company information incorrectly. The change reverses the order of the issuer and receiver addresses, presenting a cleaner and more standard layout. This ensures invoices are clearly identified as originating from Odoo and improves readability.
Original PR description
When an invoice is received through Peppol, it may not contain an embed PDF. If no, we create one. However, due to several complaints, this commit exchange the place of the issuer and receiver addresses and information. Company information were rendered in the header of the document through the external_layout. Switching to the internal layer avoid doing so. opw-5980655 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259578 Forward-Port-Of: odoo/odoo#254693
This update fixes an issue where the order report incorrectly showed a zero amount in the "Down Payments" section header. The change ensures that this section header displays correctly, providing a cleaner and more accurate report for customers and internal teams. This improves the clarity and professionalism of sales reports.
Original PR description
When creating an order with a down payment, the printed order report incorrectly shows a zero amount on the “Down Payments” line. This line acts as a section header and should not display any amount. opw-5446875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242833
This update enables quick checkout for event tickets, addressing a previous restriction that required full billing details. It recognizes that event locations are typically used for tax purposes, not customer addresses, and avoids a frustrating user experience. A system parameter allows businesses to enable or disable this feature based on their needs.
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 Forward-Port-Of: odoo/odoo#259275 Forward-Port-Of: odoo/odoo#258347
This update corrects a bug in the Timesheet Assistant that caused incorrect project suggestions when using aw.rules without associated tasks. The fix ensures that suggestions accurately reflect the project defined in the rule, improving the assistant's usability and data accuracy. This resolves a potential issue where users wouldn't see relevant project suggestions.
Original PR description
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current…
Steps to Reproduce --- - Define an aw.rule with a project set without a task (false) - The rule regex matches a desktop app event (e.g. Discord window) - Open the Timesheets Assistant for the current day Current Behavior --- - The matched event has _res_model set to "project.task" and _res_id set to undefined, despite no task being configured on the rule - The suggestion appears as "Unmatched" in the assistant even though a project was correctly defined on the rule Expected Behavior --- - The matched event should have _res_model set to "project.project" and _res_id set to the rule's project_id - The suggestion should appear under the configured project Issue --- - In extractWatcherActivity(), both project_id and task_id blocks used != null as the guard condition - When task_id is false, false[0] is undefined, overwriting the correctly set _res_model i.e. "project.project" and _res_id from the project_id block with "project.task" and undefined _res_id Fix --- - Replace with a truthy check task - 6089410
This update resolves an issue where tests were failing due to lingering data from previous attempts. The fix ensures each test run starts with a clean slate, preventing errors and improving overall test reliability. This change enhances the stability of the Odoo testing framework.
Original PR description
The autoretry don't recreate the test instance meaning that some pollution can remain there breaking the next test with a strange error. This pr recreates the test instance for each retry to avoid this kind of issue, and move the retry mechanism to the suite level. The core part of the fix is `test = test.__class__(test._testMethodName) # re-create the test to reset its state` While on it, moving the retry mechanism in the test suite since it makes more sense and allow a better control on what is retried or not since we don't rely on inheritance, and avoid dirty code with super(test) call to recreate the instance and execute it again. The tests needs to be adapted since the retry attribute is now in the loop, but we can have a quite reliable way to know if we are in a retry or not using inspect. Forward-Port-Of: odoo/odoo#258833
This update fixes an issue where stock quantities were incorrectly displayed for a company when a purchase order was processed through a different company in a multi-company setup. Now, stock quantities are correctly restricted based on the product's assigned company, preventing access errors and ensuring accurate reporting.
Original PR description
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company…
**Purpose:** Since a stock.quant is a combination of the stock move lines of a product and a location, it should be restricted by the product's company. **Before this commit:** In a multi-company environment. If a purchase order with product from company 1 is being confirmed, received, and validated when company 2 is being selected as the primary active company while company 1 is also checked. It will create a stock.quant that is searchable for company 2. However, it will raise an error when company 2 is trying to access it. **After this commit:** Even if the stock.quant is created when company 2 is the primary active company, it will not be searchable for company 2 since the product's company is company 1. **Steps to Reproduce on Runbot:** - Create a storable product exclusive to Company A - Create & validate a receipt for that product in Company A. - Switch to Company B -> Reporting > Locations > Remove all filters: The negative quant for the product in Partners/Vendors is visible. opw-6082330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259733 Forward-Port-Of: odoo/odoo#257211
This update fixes an issue with invoice rounding related to down payments. The system now correctly uses specific currency values to ensure the total invoice amount matches expected calculations, particularly when a down payment is involved. This improves the accuracy of financial reporting.
Original PR description
'total_excluded_currency' is for the base amount. 'base_amount_currency' should be used only when getting the base per tax. When dealing with a down payment, a distortion in the taxes amounts might be introduced to ensure the total of the invoice is exactly the expected one. opw-6060486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259426
This update corrects a bug in the landed cost calculation process. Previously, the system incorrectly multiplied currency rates, leading to inflated landed cost figures. The fix ensures landed costs are calculated accurately based on the correct exchange rate, resolving a discrepancy in pricing.
Original PR description
Issue introduced by commit daf196e365f481ffcc8b56664fa361fa9c9bbda9
Steps to reproduce:
- Enable two currencies (e.g., USD and EUR)
- Set exchange rate: 2 EUR = 1 USD
- Set current company currency to USD
- Create a service product "Landed Cost":
- Purchase tab:
- Mark as "Is a Landed Cost"
- Cost: $10
- Create a bill:
- Vendor: any vendor
- Currency: EUR
- Add 1 unit of "Landed Cost" → correctly shows 20 EUR
- Click the "Create Landed Cost" button
Expected behavior:
Landed cost should be calculated as $10
Actual behavior:
Landed cost is incorrectly calculated as $40, because the AML (Account Move Line) price subtotal is multiplied by the currency exchange rate (2) instead of dividing.
opw-6121706
opw-6121407
Opw-6124771
Opw-6123193
Forward-Port-Of: odoo/odoo#259632This update resolves an issue where dropdowns within knowledge articles weren't closing properly when clicking outside the embedded view. The fix adjusts the way the system detects clicks, ensuring dropdowns close as expected. This improves the user experience when working with knowledge articles.
Original PR description
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first…
Steps to reproduce: - Go to knowledge - Type "/view" in the article -> add a list view - Open a dropdown in that list view (e.g. the cog icon next to "New") - Click outside the list view (e.g. first paragraph of the knowledge article that contains the list view) => The dropdown does not close Commit [1] removed the `activeEl` param of `popoverCloseOnClickAway`, and inverted the need for the knowledge patch added at [2] (before, it was needed to be able to close dropdowns by clicking inside knowledge embedded views, it is now needed to be able to close them by clicking outside the embedded views). In 19.2, this patch could be removed entirely as [3] made a generic solution for this to work (it will probably be done once this reaches master though). [1]: https://github.com/odoo/odoo/commit/1fb00045c6826ee7c8a7581ff4ab9b3eb2e83478 [2]: https://github.com/odoo/enterprise/commit/97c600ca35ae0513860467e572d587b977617d36 [3]: https://github.com/odoo/odoo/commit/48be3442b2b022c18d9e5d4fc8b9631563094d8e Forward-Port-Of: odoo/enterprise#114082
This update corrects an issue where negative numbers in accounting reports (like customer statements) were split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience when reviewing financial data.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727
This update resolves a potential issue where Odoo could create related fields that rely on non-searchable data, leading to errors in searching, reporting, and overall system stability. By adding validation, this change ensures related fields always use stored data, improving data consistency and reliability.
Original PR description
**Steps to Reproduce:** - Create a new database. - Install any module (for example, Sale). - Go to Settings → Technical → Database Structure → Fields. - Create a new field using Studio or manually. -…
**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Sale).
- Go to Settings → Technical → Database Structure → Fields.
- Create a new field using Studio or manually.
- Set the field as a related field using a path that includes a non-stored field (e.g., product_variant_id.active where product_variant_id is non-stored). Save the field.
**Issue:**
- Odoo allows defining related fields that depend on non-stored (non-searchable) fields in the dependency chain.
- This leads to runtime issues such as:
- Cannot convert field to SQL because it is not stored
- Failures in search, domains, and reporting
- Inconsistent behavior depending on usage context
- Currently, no validation prevents users from configuring such invalid related fields.
**Solution:**
- Add validation in the related field resolution logic to ensure that all fields In the related path are stored.
- Raise a ValidationError when a non-stored field is encountered in the related path, clearly indicating the offending field and model.
This prevents invalid related field configurations at creation time and ensures data consistency and predictable behavior across ORM operations.
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#259309This update resolves an issue where POS users with limited access rights were unable to fully close sessions when using the Fiskaly integration in Germany. The fix removes unnecessary security checks, allowing users to complete the closing process without requiring administrator privileges. This ensures a smoother user experience for POS operations.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#113714 Forward-Port-Of: odoo/enterprise#112618
This update resolves an issue where the 'Create a Payslip' button was unresponsive when no payslips existed in the W2 report. The fix corrects a technical error in the system's code that prevented the button from functioning properly. This ensures users can consistently generate W2 reports.
Original PR description
1.Install l10n_us_hr_payroll 2 Navigate to Payroll>Reporting>W2 Report. 3.Open/Create W2 form and try to add payslip by clicking "Add a line". 4."Create a payslip" button appears if their are no valid payslips. 5.Click it, it won't work! Root cause: - `onAdd` bind was missing in the controller - Renderer applied an additional `.bind(...)`, breaking the callback Fix: - Pass a dedicated `createNewPayslip` action from controller - Remove double binding in renderer - Forward callback directly to helper component task-[5928770](https://www.odoo.com/odoo/project/1251/tasks/5928770) Forward-Port-Of: odoo/enterprise#113994 Forward-Port-Of: odoo/enterprise#111735
This update resolves a crash that occurred when confirming rental orders with kit products using multiple pack locations. The change uses a safer method to handle multiple pick transfers, preventing the system from failing due to a single record requirement. This ensures smooth rental order processing for kit-based rentals.
Original PR description
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries…
Problem: When you confirm a rental order that has a kit product whose components use two different pack locations Odoo crashes with a singleton error. You get this singleton error because Odoo tries to assign both picks as the `return_id` because they share the same `sale.order.line` here: https://github.com/odoo/enterprise/blob/2212b3f3f3d90894dd6351defe0d3ca090584955/sale_stock_renting/models/sale_order_line.py#L404
Purpose: Use [:1] to safely handle the case where multiple pick transfers are created, avoiding a crash when assigning return_id which expects a single record.
Steps to Reproduce on Runbot:
1. Enable mutli-step routes and rental transfers.
2. Set the warehouse to 3-step delivery.
3. Copy the existing packing location.
4. Copy the existing pick operation type and set the destination location to the new packing location.
5. Create a new route.
6. Create new rules on this new route with the following configurations:
1. Rule 1
1. Action: Pull
2. Source location: WH/Stock
3. Destination location: Partners/Customers
4. Operation type: The new pick operation type
2. Rule 2
1. Action: Push
2. Source location: New pack location
3. Destination location: WH/Output
4. Operation type: Pack
3. Rule 3
1. Action: Push
2. Source location: WH/Output
3. Destination location: Partners/Customers
4. Operation type: Delivery
7. Create 2 component products tracked by inventory, and apply the new route on one of the component products.
8. Create a new rental product with a kit, which has the 2 component products.
9. Create a new rental order for the kit product and confirm it.
opw-6026918
Forward-Port-Of: odoo/enterprise#113879
Forward-Port-Of: odoo/enterprise#112543This update fixes an issue where refunds weren't correctly reflected when calculating outstanding balances in the Point of Sale (POS) system. Previously, only regular orders were considered, leading to inaccurate due amounts. Now, refund orders with negative totals are included, ensuring accurate due calculations and a more reliable user experience.
Original PR description
Step to reproduce - install "pos_settle_due" - have a customer, A and a pos with payment method "customer Account" - start pos, add 3 qty of product with unit price 10$ with partner A - use payment method "customer Account" i.e. of type "pay_later" (do not invoice orders) - refund 1 qty of previous order using same payment method - go to partner list, notice A has 20$ as due - click on "hamburger btn" > settle due amount Observation: - notice we only get the order amount as due i.e order with 30$ - we should have received the refund order too, so that net due of 20$ can be processed Cause: - currently, we didn't considered refunds orders at all, when settling dues Fix: - now we consider order with total < 0 i.e refund orders to be included for settlement opw-5869313 Forward-Port-Of: odoo/enterprise#113663 Forward-Port-Of: odoo/enterprise#107883
A recent update introduced an unnecessary call to external tax services, causing the checkout process to become unresponsive for users with Brazilian tax configurations (CPF). This fix removes the problematic call, streamlining the process and resolving the issue. It ensures a smoother checkout experience for customers using the Avatax module.
Original PR description
Issue: --- The extra external_tax call introduced in odoo/enterprise#101579 is causing multiple issues: 1- It doesn't catch errors while `_get_and_set_external_taxes_on_eligible_records` easily raises errors, causing uncatch errors in `website_sale`. 2- Extra unnecessary external api call in non-express checkout methods which is not desirable. Steps to reproduce: --- 1- Install l10n_br_avatax_sale, website_sale 2- Using a public user, add a product to cart and got to checkout. 3- In the address form, use CPF identification type. Outcome: The confirm button is unresponsive. Cause: --- This is due to uncatch error raised by external tax call, while it was not necessary at this step of this flow to call external tax api. opw-6005767 Forward-Port-Of: odoo/enterprise#114031 Forward-Port-Of: odoo/enterprise#112515
A technical issue causing negative values in the Luxembourg tax report's calculations has been resolved. The formula was incorrectly referencing a negative value, leading to inaccurate reporting. This update corrects the calculation, ensuring the tax report displays the correct credited amounts for Luxembourg companies.
Original PR description
Steps to reproduce: - Install `l10n_lu` module - Switch to `LU Company` - Create a invoice and in journal items use tax grid `226` - Open the Tax Report and check the line `226 - Supplies carried out within the scope of the special arrangement of art. 56sexies` - The value appears negative instead of positive. Cause: This issue is caused by the major tax revamp introduced in version 19 [commit]. The credited amount is currently displayed as a negative value, which is incorrect, it should be shown as positive. Solution: To resolve this issue, the formula has been modified from `226` to `-226`. [commit]: https://github.com/odoo/odoo/commit/17a6117ed88c29b5bc4db0c872bcdbc109a7d98b#diff-3441c5d05315ec0562923797f973eae66488452a6772d23e198998c1890aa06c opw-6050665 Forward-Port-Of: odoo/enterprise#113952
This update resolves an issue where the system incorrectly processed DTE XML files from the fetchmail server when a specific LATAM accounting setting wasn't enabled. The fix ensures the correct journal ID is used, preventing errors and allowing proper account move calculations. This improves the reliability of importing invoices from Chile.
Original PR description
Currently, when receiving a DTE XML fetched by the fetchmail server, if there is no purchase journal with `l10n_latam_use_documents` enabled, an empty recordset (account.journal()) is set in the default context values. This prevents the proper computation of the field and raises an error, since the `journal_id` is mandatory on account moves. Steps to reproduce: - Ensure you have no purchase journal with `l10n_latam_use_documents` enabled - Simulate the reception of a DTE XML via the fetchmail server - Observe the error: "NotNullViolation: null value in column 'journal_id'" opw-5950116 opw-6111041 Forward-Port-Of: odoo/enterprise#112168
This update resolves an issue where database synchronization would fail when a user's access was removed. Now, the synchronization process completes gracefully, ensuring data consistency even if user access is no longer valid. This enhances the stability of our SaaS offering.
Original PR description
The aim of this commit is to allow a db_user to synchronize a database without facing a Traceback. Context: - A new document has been received by a remote db and we try to synchronize it. - The current user access has been removed from the remote db. - The database is unreachable. Before this commit: In all 3 previous cases, an access error would be raised because a db_user can't write on a database. After this commit: The synchronization finish gracefully and the db_user should have lost his access if it was removed from the remote db. task-id: 6046087 Forward-Port-Of: odoo/enterprise#113826
This update fixes a bug that prevented users from saving appointments when removing the organizer. The issue stemmed from a mismatch in data expectations within the Google Calendar integration. By adjusting the code, the system now correctly handles appointments without a designated organizer, ensuring smooth appointment creation.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update resolves an issue where delivery confirmations were failing due to missing tracking data from Easypost. The fix ensures that picking is correctly validated and the carrier tracking URL is empty, preventing shipping creation in Easypost while maintaining accurate order status in Odoo. Easypost support suggested a slight delay between order placement and tracking retrieval as a potential workaround.
Original PR description
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs…
Problem: 'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend. Solution: Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty. Transcript from Easypost support: << I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >> opw-5402415 Forward-Port-Of: odoo/enterprise#111833
This update fixes a reporting issue on the Swiss Balance Sheet by changing the date range used to calculate 'Current Year Retained Earnings'. Previously, the report used a broad date range, leading to inaccurate figures. This change ensures the report accurately reflects retained earnings within the current fiscal year.
Original PR description
The "Current Year Retained Earnings" (CH_299_A) line on the Swiss Balance Sheet was using the default `strict_range` date scope. This commit forces the `date_scope` to `from_fiscalyear`. task-6119493 Forward-Port-Of: odoo/enterprise#113920
This update enables quick checkout by default for event and appointment bookings, streamlining the purchase process. Previously, a broad change risked disrupting other checkout flows. A system parameter allows businesses to retain full billing address details if needed, ensuring flexibility.
Original PR description
Forward-Port-Of: odoo/enterprise#113885 Forward-Port-Of: odoo/enterprise#113575