Daily updates from Odoo
Wednesday, January 7, 2026
289 changes
22 changes
Resolved issues and error corrections
This update optimizes the payroll calculation process by reducing unnecessary computations and streamlining data filtering. The changes enhance the system's performance and stability, particularly within the HR payroll module. This ensures accurate and efficient payroll processing.
Original PR description
## [FIX] hr_payroll: improve performance of _compute_issues Before this commit, the compute of issues field in `hr.payslip` model computes more than expected, that is, that compute computes other records than the ones contained in self. This part is not really needed since those payslips will surely be triggered afterwards thanks to the fields dependencies set on the compute method. That compute does a lot of filtered to almost do the same filter. The translation of each warning are called for payslips in which we detect there is an issue/warning. This commit reviews the compute method to reduce the computation cost. ## [FIX] hr_payroll: add hook to be able to alter the condition in filtered This commit adds a hook to be able to easily change the condition made in a filtered instead of doing 2 times the filtered.
This update resolves an issue where the 'View Reactions' button in the customer portal was causing errors. Now, users can reliably click this button and access the reactions list for messages without encountering technical problems. This improves the overall user experience and ensures consistent functionality.
Original PR description
Before this PR: - Clicking the 'View Reactions' button from the message right-click menu was throwing an error. After this PR: - Clicking the 'View Reactions' button from the message right-click menu now opens the reactions list correctly without errors. task-5449199 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where push notifications could fail due to incorrect device registration settings. Specifically, it handles cases where the old subscription data isn't available during push subscription changes, and addresses issues with invalid domain names (like `.invalid`) used in push notification endpoints.
Original PR description
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring…
[FIX] mail: avoid error on service worker push subscription change Sometimes, the `pushsubscriptionchange` event is called without an `oldSubscription` defined, which can lead to an error occurring inside the service worker. Steps to reproduce: 1. Enable notification in Odoo. 2. Reset the permission in the Chrome interface 3. Re-enable the permission inside the discuss systray by clicking on the Odoobot message. => The pushsubscriptionchange is called without an oldSubscription [FIX] mail: ir_cron_web_push_notification are now more robust With a user having 5 registered devices for push notifications if a browser registers with an endpoint that has a wrong domain such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX the cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. [FIX] mail: push_to_end_point method to support .invalid TLD if a browser registers with an endpoint that has a TLD `.invalid` such as https://permanently-removed.invalid/fcm/send/XXXXXXXXXXXXX The TLD `.invalid`[1] is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid. The cron job cannot resolve the invalid domain of the endpoint and ends up disabling it. So we need to unregister a device with an endpoint with a `.invalid` TLD. [1]: https://datatracker.ietf.org/doc/html/rfc2606#section-2 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242428 Forward-Port-Of: odoo/odoo#240502
This update corrects a visual inconsistency in the Odoo chatter interface. Previously, paragraphs added in the composer didn't maintain their bottom margin when posted to the chat, leading to a mismatched appearance. This fix ensures that the spacing between paragraphs in the chatter matches the composer and sent emails, improving the overall user experience.
Original PR description
Problem: When adding a paragraph in the composer and sending the message, the paragraph posted in the chatter has a `margin-bottom` of 0. Cause: Paragraphs in the chatter rendering override the default bottom margin, resulting in inconsistent spacing compared to the composer and the sent email. Solution: Update selector to only target the last `p`. Steps to reproduce: - Open the chatter composer. - Add a paragraph using "/Paragraph". - Add some text. - Send the message. - Observe that the message posted in the chatter has no bottom margin, unlike in the composer. opw-5378129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240082
This update fixes a limitation in the HTML editor where code blocks with syntax highlighting couldn't be easily converted back to regular paragraphs. A new button has been added to allow users to seamlessly switch between syntax highlighting and standard paragraph formatting within code blocks, improving note editing flexibility.
Original PR description
When syntax highlighting is activated on code blocks, neither the powerbox nor the toolbar is available inside the block, making it impossible to convert it back into a paragraph. This commit adds a button to convert such code blocks back into paragraphs. Steps to reproduce: - Go to a "To Do" note - Insert a code block with `/code` => There was no way to convert it back to a paragraph task-5241467 Forward-Port-Of: odoo/odoo#240692
This update resolves a technical issue that was causing duplicate test runs, leading to instability in the Odoo base module tests. The fix ensures tests run correctly and reliably, improving the overall quality and stability of the Odoo platform. This change primarily impacts the internal testing process.
This update fixes an issue where discount values were calculated incorrectly when using promotion programs on specific products with tax included. The fix ensures that discounts are applied accurately to the product's base price, leading to more reliable pricing and promotions in the Point of Sale system. This improves the accuracy of sales calculations.
Original PR description
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of…
When using a promotion program applied only on specific products with tax included prices, the discount value was incorrect. Steps to reproduce: ------------------- * Create a product with a price of 100$ and tax of 10% included * Create a promotion program with: - Apply on: Specific Products (the product created above) - Discount Type: $ Fixed Discount - Discount Value: 10$ * Open PoS and add the product to the order * Apply the promotion code > Observation: The value of the discount is 9.09$ instead of 10$ The same steps also applies to the discount reward applied on the whole order. Why the fix: ------------ When computing the discountable amount for the promotion it would take the amount excluding tax instead of the base price. The base price should be the unit price of the product multiplied by the quantity. As it was before here : https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/point_of_sale/static/src/app/models/pos_order_line.js#L470-L474 https://github.com/odoo/odoo/blob/8568baa35c9caa4c8cd3b1f5d737e1ecbec76434/addons/pos_loyalty/static/src/app/models/pos_order.js#L1112 To do so we modified the accounting helpers to provide this value instead of computing it manually. opw-[5260067](https://www.odoo.com/web#id=5260067&view_type=form&model=project.task) opw-[5242194](https://www.odoo.com/web#id=5242194&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#240289
This update resolves an issue where stat buttons appearing within bottom sheets were sometimes displaying incorrectly, particularly in modules like Sale Project and Timesheet. This fix ensures that stat buttons function reliably within bottom sheet displays, improving the user experience.
Original PR description
when a stat button is displayed inside a bottom sheet, it can appear broken (e.g., in sale_project, sale_timesheet). task-5359751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238162
This update fixes a bug in the Point of Sale (POS) system where variant names weren't correctly displayed when a combo product was selected. Previously, if a combo contained a variant, the variant's name wouldn't appear on the order. This change ensures that variant names are accurately shown, improving the user experience and order accuracy.
Original PR description
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create…
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create a combo choice and add one of his variants * Create a combo product and add the combo * Open an store that sells this combo * Select the combo and choose the product with variant and confirm the selection Issue : On the left size in the order the variant name will not appear. ### Observation: When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33 ------------ When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered. The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products. opw-5037355 Forward-Port-Of: odoo/odoo#239314 Forward-Port-Of: odoo/odoo#227176
This update fixes a previous issue where the 'Space' key wasn't functioning correctly when creating records in Odoo's Kanban views. Now, users can reliably use the 'Space' key, and 'Shift+Space', to navigate the 'Edit' and 'Trash' options, improving workflow efficiency.
Original PR description
In kanban's quick create record, the 'Space' key is not working on 'Edit' and 'Trash' buttons as earlier versions. After this commit 'Space' key will work as expected. Task-5319051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239478
This update fixes a recurring test failure in the MRP planning module. The change creates the planning leave manually instead of relying on a complex calculation, making the test more reliable and consistent. This improves the overall stability of the Odoo system.
Original PR description
Before this commit: Introduced in https://github.com/odoo/odoo/commit/d06dcfbca96273b540c87252b9188603879ac1b4, the test was failing on runbot in some cases. The issue is deterministic, but requires a specific set of modules installed to fail. After this commit: Use a more robust approach in the test, by creating the leave manually instead of computing the number of operations needed. runbot-234638 Forward-Port-Of: odoo/odoo#241928 Forward-Port-Of: odoo/odoo#239717
This update resolves an issue where arrow keys didn't function properly when adjusting range values (like intensity) in certain Odoo features. The fix replaces a flawed conversion method with a more accurate one, ensuring that fractional steps are handled correctly. This improves usability for users adjusting these settings.
Original PR description
**Problem** Arrow-keys don't work properly on `BuilderRange` if the `step` value is fractional. **How to reproduce** The problem is present on every `BuilderRange` having fractional `step`. For example: snippet `s_parallax` -> set "Scroll Effect" to "Parallax to Top" -> "Intensity" range. **Why the problem happens** The method `BuilderRange.onKeydown` retrieves the range value as a string, converts it to a number using `parseInt`, and then adds or subtracts the step value. Of course, `parseInt` is inappropriate when the value is expected to be fractional. **Fix** `parseInt` has been replaced by `parseFloat`. task-5405036 Forward-Port-Of: odoo/odoo#241141 Forward-Port-Of: odoo/odoo#239428
This update corrects a bug where changes made to nested website snippets (accordions and blockquotes) unintentionally affected other nested instances. The fix ensures that edits are applied only to the specific snippet being edited, improving the consistency and reliability of the website builder. This resolves a previous issue impacting user customization.
Original PR description
This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested…
This commit fixes some issues that occur when editing nested instances of `s_accordion` and `s_blockquote` snippets. In all cases, changes applied to a parent unintentionally propagate to nested snippets. **Accordion issues** How to reproduce: drop two nested `s_accordion` snippets. Then: 1. Change the outer "Style" from "boxed" to "highlight active" -> both accordion change, 2. Change the outer "Round Corners" -> both accordion change, 3. Change the outer "Icon Position" -> both accordion change, 4. Change the outer "Icons" style -> both accordion change. **Blockquote issues** How to reproduce: drop two nested `s_blockquote` snippets. Then: 1. Change the outer "Decoration" -> both blockquotes change, 2. Set the inner "Decoration" to "Icon" -> works only if the outer snippet has icon too, 3. Change the outer "Author Alignment" -> only the inner blockquote changes. **Cause** The above issues occur because certain `applyTo` and certain CSS selectors match all nested elements rather than restricting the scope only to the snippet being edited. **Fix** The relevant `applyTo` and CSS rules now use more specific selectors. **Note** See also https://github.com/odoo/odoo/pull/237733 task-5362171 Forward-Port-Of: odoo/odoo#242077
This update resolves an issue where IoT devices were incorrectly attempting to retrieve their MAC addresses. The change ensures the system correctly obtains the MAC address, improving the functionality of the IoT integration. This ensures reliable data transmission from IoT devices to Odoo.
Original PR description
odoo/odoo#242356 fw port introduced an issue where the iot tries to get the mac address from `helpers` instead of `system`.
This update corrects a technical issue within the IoT Box image build process. The fix ensures the necessary software components are included, preventing a potential error that could have impacted image deployment. This resolves a minor technical problem without affecting core functionality.
Original PR description
As the image is built on a "non-RPI" linux machine, gatt isn't installed at build time. It requires the image to update itself to get the package. Even if the gatt package is only used for bluetooth caliper devices that are not widely used, this fix avoids a traceback.
This update fixes an issue where combo line prices were incorrectly set to 'automatic'. The change ensures combo line price types remain as originally defined, preventing conflicts with price updates and improving the accuracy of sales calculations. This ensures consistent pricing for combo products within the Point of Sale system.
Original PR description
After commit https://github.com/odoo/odoo/commit/69057e41fb4cd800d23401ead8ae11bf7cba7c64, the price type of combo lines was changed to 'automatic' when creating the combo line. This caused the set pricelist logic to update the price of combo lines with automatic price type, which conflicts with the intended behavior. This commit ensures that the price type of combo lines is preserved as original in cases where we want to update the price, and only set to automatic in cases like loading a sale order or refunding an order. opw-5240429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241737 Forward-Port-Of: odoo/odoo#234575
This update fixes a bug that caused confusing error messages when using QWeb with `etree` nodes. The improved logging now includes the surrounding code snippet, providing immediate context for developers and significantly simplifying the debugging process.
Original PR description
This PR fixes the error logging when QWeb is used with an `etree` node instead of a standard xmlid or id, to display the path of the directives (xml node) crossed. I have also improved the logging output when running with `--dev=qweb`: the error message now includes the generated code snippet surrounding the line that caused the error. This should make debugging much more intuitive by providing immediate context for the failure. Forward-Port-Of: odoo/odoo#242251
This update corrects a redundant permission check within the VoIP CRM module. Previously, access was granted based on a broader group, but it's now limited to the more specific 'salesman' group. This ensures only authorized users can access VoIP CRM features, enhancing overall system security.
Original PR description
`group_sale_manager` implies `group_sale_salesman`[1] [2]. Just checking `group_sale_salesman` is enough. [1]: https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/addons/sales_team/security/sales_team_security.xml#L25-L33 [2]: https://github.com/odoo/odoo/blob/54681272e9f00a171fe49f690979e2a8353ff5fb/addons/sales_team/security/sales_team_security.xml#L17-L23i Task-5461729 Forward-Port-Of: odoo/enterprise#103378
This update resolves an issue where UI tours were failing due to a change in how the product column was displayed on invoices and bills. The fix ensures the column is visible by default within the tours, restoring their intended functionality and improving the user experience. Runbot tests have confirmed the fix.
Original PR description
Commit 9c8e012 changed the visibility of the product column on invoices and bills. This caused several tours to fail as they expected the column to be visible by default. This commit fixes the failures by explicitly toggling the column visibility within the affected tours when required. runbot-234710 runbot-234871 runbot-234872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242247
This update fixes several issues within the spreadsheet component, ensuring smoother operation and improved data handling. Specifically, it addresses problems with date validation, grid resizing, and error recovery, enhancing the overall user experience. This is a routine maintenance update to maintain the stability of the spreadsheet functionality.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/febc3e9dbf [REL] 19.1.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/febc3e9dbf [REL] 19.1.2 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/3b078a53a3 [FIX] session: always return a Promise [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/5a41fa94fc [FIX] session: recover from errors when sending messages [Task: 5469116](https://www.odoo.com/odoo/2328/tasks/5469116) https://github.com/odoo/o-spreadsheet/commit/a2e90fb875 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) https://github.com/odoo/o-spreadsheet/commit/287f807aba [FIX] dashboard: properly handle grid resize in dashboard mode [Task: 5223156](https://www.odoo.com/odoo/2328/tasks/5223156) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes a bug that caused data loss when users disconnected during spreadsheet revisions. The system now automatically retries sending messages, ensuring that all changes are successfully transmitted and preventing data loss due to interruptions. This enhances the overall stability and reliability of the spreadsheet feature.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116
This update resolves an issue where creating a new spreadsheet template within the Quality Control app would trigger a validation error due to a missing default name. The fix provides a default name, ensuring the template creation process functions correctly and avoids user frustration.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671
7 changes
Resolved issues and error corrections
This update resolves an issue where a specific product variant (white) wasn't consistently added to the cart during the subscription setup tour. The fix utilizes a click action instead of a checkbox, ensuring a more reliable and predictable user experience for subscription purchases.
Original PR description
In this commit we fix undeterministic error in tour sale_subscription_add_to_cart. We can see on https://runbot.odoo.com/odoo/error/234505 that variant white can not be always selected. For that we prefer use click action instead of check action.
This update fixes an issue where product documents weren't being added to PDF quotes after they were confirmed. Previously, confirmed quotes didn't include selected documents. Now, a new setting allows users to ensure all desired documents are always included in the PDF quote, improving the accuracy of sales materials.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Add product documents, headers or footers to a quotation; 2. confirm quotation; 3. print quotation. Issue ----- Extra documents aren't added to the PDF, even though they show up as selected in the quotation builder. Cause ----- As of commit b02f53d, any quotation documents linked to a sales order are simply ignored for confirmed orders. Solution -------- Add a `sale.always_include_selected_documents` config parameter, allowing users to keep including the selected documents on confirmed orders. opw-5242743 Forward-Port-Of: odoo/odoo#235778
This update resolves an issue with the 'leitweg-id' field in xRechnung invoices, ensuring accurate data transmission. The fix involved updating a helper function to correctly format this ID, which was previously missed by existing tests. This ensures compliance with invoicing standards.
Original PR description
Correction of the forward port for the leitweg-id in the 'cbc:BuyerReference' field for the xRechnung invoice. The 'export_invoice_vals' function is an old helper that is not used by default anymore (but used by the tests, that is why the tests did not catch the error). I added the if statement in the corresponding new helper: '_add_invoice_header_nodes' and changed the test for it to catch the error. Related: #236333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241982
This update ensures that variant names are correctly displayed on POS orders when a product is included in a combo. Previously, the system didn't show variant information for combo products with instantly generated variants. This fix corrects a technical issue related to how the POS system retrieves product details, improving the user experience and accuracy of order information.
Original PR description
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create…
In POS, if in a combo, one of option has instantly created variant it will not show the variant name in the order ### Steps to reproduce: * Create a product with instantly generated variants * Create a combo choice and add one of his variants * Create a combo product and add the combo * Open an store that sells this combo * Select the combo and choose the product with variant and confirm the selection Issue : On the left size in the order the variant name will not appear. ### Observation: When it tries to retrieve the attribute information for the variant https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/services/pos_store.js#L1048 It is empty since during the call of computeComboItems the attribute was not retrieved for this scenario. https://github.com/odoo/odoo/blob/942b7a21d7e0eb15133f4af1b47e68f48dec70c7/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L31-L33 ------------ When adding a always variant to a combo they are considered like their own product, and attribute.extra_price should not be considered. The extra price for an always variant is setup in the combo with comboItem.extra_price like stand alone products. opw-5037355 Forward-Port-Of: odoo/odoo#239314 Forward-Port-Of: odoo/odoo#227176
This update fixes a previous issue where payments made on the website weren't properly reflected in the POS. Now, the POS automatically recognizes and accounts for payments made through ecommerce, creating down payment lines for existing orders. Additionally, fully paid orders without invoices won't appear in the POS to prevent duplicate payments.
Original PR description
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the…
Before, if you paid for something on the website with ecommerce, it would create a sale order with a transaction linked to it, but no invoice. So in the POS the order would show up in the Quotation/Order menu, but the POS didn't have any reference on the payment, so you would have to create another duplicate payment. Now the amount_paid (which is the amount already paid in transactions) is taken into account when calculating what's left to pay in the POS. So anytime you open a sale order in the POS it should create a down payment line for anything already paid on the website (the same as we were already doing for invoices). Also to avoid double payments, now the sale orders which have been already paid in full, even if they are not invoiced yet, will not show up in the POS. The invoice can still be created normally from the Sale app in Odoo. Task-5187602 Community PR-[#232841](https://github.com/odoo/odoo/pull/232841) Backport-[#96876](#https://github.com/odoo/enterprise/pull/96876) Original Task-5138081 Forward-Port-Of: odoo/enterprise#103350 Forward-Port-Of: odoo/enterprise#98029
This update resolves an issue where creating a new spreadsheet template within the Quality Control app would trigger a validation error due to a missing default name. The fix provides a default name, ensuring the template creation process functions correctly and users can easily create new spreadsheets.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671
This update ensures that downpayment accounts are correctly applied when calculating taxes externally (like Avatax). Previously, invoices always used the default income account, even with a downpayment account set. Now, the system prioritizes the downpayment account from the product category or falls back to the company's default if no category is defined, aligning with standard downpayment behavior.
Original PR description
**Problem:** When calculating taxes externally (such as Avatax) and a downpayment is made, the line on the invoice will always use the default income account, regardless of the downpayment account set as a company default. This is inconsistent with the standard behavior of downpayments, which will use the downpayment account set on the product's category instead of the income account (which themselves may come from company defaults). **Solution:** Check if there's a company default for downpayment account on product category and use this account for the downpayment line instead of the income account. opw-5171067 Forward-Port-Of: odoo/enterprise#101570 Forward-Port-Of: odoo/enterprise#101524
11 changes
Resolved issues and error corrections
This update fixes an error that occurred when users set a negative value for the fiscal year end day in the Tax Returns view. The fix prevents invalid data from being saved, ensuring the Tax Returns functionality operates correctly. This resolves a potential disruption to financial reporting.
Original PR description
Currently, an error occurs when user tries to open the Tax Return view. **Steps to Reproduce:** - Install the `Accounting` module. - Go to `Tax Returns` and set the `Fiscal Year End Day to negative…
Currently, an error occurs when user tries to open the Tax Return view. **Steps to Reproduce:** - Install the `Accounting` module. - Go to `Tax Returns` and set the `Fiscal Year End Day to negative value`, then click `Apply`. **Error:** `ValueError: day is out of range for month.` **Cause:** - The field is related to the `company's fiscalyear_last_day` [1]. - When the user enters a `negative value`, that invalid value is written directly to the `company's fiscal year last day`[2] . - When the user opens the `Tax Returns`, it going to compute the `fiscal year dates` [4]. Since the day value is negative, it raises error [5] because the day is out of range for the month. **Fix:** - This commit ensures that a validation error is raised when a user enters zero or negative fiscal year date. - In 18.3, setting the value to 0 falls back to the previously defined company value [2]. - In 19.0, however, the value 0 is incorrectly saved on the company [3], causing an error. - This fix restores the correct behavior and resolves the issue in 19.0 as well. [1]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L17-L18 [2]: https://github.com/odoo/odoo/blob/45ca03fcb77febf4f373fe35f0242720e88cb85b/addons/account/wizard/setup_wizards.py#L49 [3]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/addons/account/wizard/setup_wizards.py#L54-L56 [4]: https://github.com/odoo/enterprise/blob/99642bdf62f8b1c653dfefdbdcd0e9258cc9e307/account_accountant/models/res_company.py#L174-L175 [5]: https://github.com/odoo/odoo/blob/27cd0a3fea1b47a85a4f3d397b052bbec08e182b/odoo/tools/date_utils.py#L242 sentry-7102968735 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A technical error occurred when switching between POS configurations with and without employee login. This fix ensures the system correctly updates its data storage (IndexedDB) to account for the 'Log in with employees' option, preventing errors during opening and closing processes. This improves the stability and reliability of the POS functionality.
Original PR description
Before this fix, a traceback occurred on the frontend when switching from a POS configuration without the “Log in with employees” option enabled to one that had it enabled. Steps to reproduce : 1. Open a PoS without "Log In With Employees" option activated 2. Close Register and go to the backend 3. Enable the "Log in with employees option" for this PoS and set some users 4. Re-open the PoS with a user and close it 5. A TB occured This traceback occurred because the IndexedDB did not include the "hr.employee" module required by the "Log in with employees" option. The fix was to upgrade the IndexedDB if a module is missing. task: 5223393 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a visual inconsistency in the Odoo chatter interface. Previously, paragraphs added in the composer didn't maintain the correct bottom margin when posted to the chat. This change ensures that messages sent via chatter display with consistent spacing, matching the composer and email versions, improving the overall user experience.
Original PR description
Problem: When adding a paragraph in the composer and sending the message, the paragraph posted in the chatter has a `margin-bottom` of 0. Cause: Paragraphs in the chatter rendering override the default bottom margin, resulting in inconsistent spacing compared to the composer and the sent email. Solution: Update selector to only target the last `p`. Steps to reproduce: - Open the chatter composer. - Add a paragraph using "/Paragraph". - Add some text. - Send the message. - Observe that the message posted in the chatter has no bottom margin, unlike in the composer. opw-5378129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240082
This update fixes an issue where product documents, headers, or footers weren't being added to PDF quotes after they were confirmed. A new configuration setting allows users to ensure these documents are always included in the final PDF, regardless of whether the order is confirmed. This improves the accuracy and completeness of sales quotes.
Original PR description
Versions -------- - saas-18.2+ Steps ----- 1. Add product documents, headers or footers to a quotation; 2. confirm quotation; 3. print quotation. Issue ----- Extra documents aren't added to the PDF, even though they show up as selected in the quotation builder. Cause ----- As of commit b02f53d, any quotation documents linked to a sales order are simply ignored for confirmed orders. Solution -------- Add a `sale.always_include_selected_documents` config parameter, allowing users to keep including the selected documents on confirmed orders. opw-5242743 Forward-Port-Of: odoo/odoo#235778
This update fixes a technical problem related to how the system acknowledges PEPPOL messages. Previously, continuous acknowledgments caused issues on the IAP side, leading to serialization errors. Now, acknowledgments are handled after the loop, ensuring smoother processing and preventing these errors.
Original PR description
The acknowledgment should not happen in the loop, but after. In a case a problem happened in the loop, it's acceptable that we end up not acknowledging messages, their status will be retrieved again at the next call. At the moment those continuous acks cause serialization issues on IAP side. task-none Forward-Port-Of: odoo/odoo#242187
This update fixes a persistent issue where inline code blocks were difficult to remove, particularly at the end of lists. The changes ensure code styles disappear cleanly when the last character is deleted, enhancing the editor's usability. It also addresses related problems with cursor placement and empty code block removal.
Original PR description
Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140 Forward-Port-Of: odoo/odoo#238552
This update corrects a technical detail in the processing of xRechnung invoices, specifically related to the 'leitweg-id' field within the invoice XML. The change ensures accurate invoice formatting for this important German tax document. The fix was triggered by a test update and addresses a minor inconsistency.
Original PR description
Correction of the forward port for the leitweg-id in the 'cbc:BuyerReference' field for the xRechnung invoice. The 'export_invoice_vals' function is an old helper that is not used by default anymore (but used by the tests, that is why the tests did not catch the error). I added the if statement in the corresponding new helper: '_add_invoice_header_nodes' and changed the test for it to catch the error. Related: #236333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241982
This update resolves an issue where grouped Kanban cards were displaying incorrectly due to a change in the Kanban templates. The fix simply removes a no-longer-needed CSS class, ensuring consistent and correct card heights are displayed within the knowledge module.
Original PR description
Since commit https://github.com/odoo/enterprise/pull/70460 and the reworking of the Kanban templates, the h-100 class was no longer correct. This PR fixes the issue by removing this class. task-5439265 Forward-Port-Of: odoo/enterprise#102801
This update corrects a problem where invoice XML files generated for Danish Nemhandel transactions were failing validation due to an incorrect assumption about the ‘PrepaidAmount’ field. The fix ensures the ‘PrepaidAmount’ node is only removed when the value is actually zero, resolving the validation issue and allowing invoices to be correctly processed.
Original PR description
To reproduce: create an invoice that is reconciled (typically a credit note) before Send&Print. Check the validity of the xml with a schematron => it fails due to the value of the PrepaidAmount The node PrepaidAmount gets removed because it was wrongly thought to be always empty. We now only remove it if the value is at 0. 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#242008
This update resolves an issue where creating a new spreadsheet template within the Quality Control app would trigger a validation error due to a missing default name. The fix provides a default name, ensuring the template creation process functions correctly and avoids the error.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671
This update corrects a bug where repeatedly validating a stock transfer in the Barcode app could create duplicate stock entries, particularly with unreserved products. The fix ensures that the validation process is only executed once, preventing data inconsistencies and saving time for users. This improves the reliability of transfer processing.
Original PR description
**Problem:** When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is…
**Problem:**
When processing a picking in Barcode, it's possible to press the validate button or scan the validate barcode multiple times before the transfer validates or raises an error. This is especially a problem when unreserved products are added to a transfer, since each additional validate call will duplicate those products (and their lot/SNs).
**Steps to Reproduce:**
- In the Barcode app, create a new internal transfer
- Scan a product, then scan the destination location 'WH/Stock/Shelf 1' ('2601892' is the barcode)
- Click the "Validate" button (or scan 'O-BTN.validate') multiple times as quickly as possible
- See that the "The transfer has been validated" toast appears (and possibly warnings about validating a done transfer) -> On the transfer, see that there are duplicated stock.move and stock.move.line
**Fix:**
Prevents the 'validate' method from executing as usual by checking if a previous call is still executing (tracked by 'isValidate').
opw-4948696
Forward-Port-Of: odoo/enterprise#101868
Forward-Port-Of: odoo/enterprise#9532918 changes
Resolved issues and error corrections
This update resolves an issue where the automated PDF generation for payroll wasn't working correctly when multiple payslips were processed. The fix addresses a technical problem with how the system identified the correct partner for PDF creation, ensuring that all payslips generate their corresponding PDF documents as expected.
Original PR description
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled…
### Issue: When running the scheduled action "Payroll: Generate pdfs" for several payslips, nothing is generated and a traceback can be seen in the logs. ### Steps to reproduce: - Disable scheduled action: "Payroll: Generate pdfs" (to avoid side effect in next step) - Refuse all time off for "Anita Oliver" (to avoid side effect in next step) - Create a user for the employee "Anita Oliver" - Link the employee and the user - Create 2 payslips - 1 for "Mitchell Admin" - 1 for "Anita Oliver" - Compute sheet and confirm both payslips - Run scheduled action: "Payroll: Generate pdfs" - Nothing happens ### Cause: The traceback is raised on the line `self._get_document_partner().id` because `_get_document_partner()` can return a recordset. ### Solution: Call `ids` instead of `id`. ### Note: Calling `_get_document_partner()` on a recordset [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/hr_payroll/models/hr_payslip.py#L444) seems unexpected as, if only one payslip in the recordset has `self.employee_id.user_id.partner_id` evaluating to `True`, then it will return only this partner, completely ignoring the other part checking `self.employee_id.work_contact_id`. The final code works fine as `_check_create_documents()` is called again individually [here](https://github.com/odoo/enterprise/blob/a0729c8d42ca93016b23e331d8f38c1f4fa88f12/documents/models/ir_attachment.py#L86). opw-5213979
This update resolves a problem where tests in the l10n_mx_edi module were consistently failing due to incorrect date calculations. The fix sets a standard test date in the middle of the year, ensuring that tests run reliably and don't depend on specific calendar dates.
Original PR description
Some tests are making "self.frozen_today - timedelta(days=1)". It means some tests are failing only the first of January. To avoid that, let's make "frozen_today" to be in the middle of the year. Forward-Port-Of: odoo/enterprise#102772
This update adjusts a timeout setting in the SMTPD tests, preventing false failures and unnecessary alerts. Previously, a very short timeout caused tests to repeatedly fail. This change ensures the tests are more reliable and avoids disruptions to the system's email functionality.
Original PR description
There are multiple cases where the SMTPD tests fail due to a timeout error. It is much worse to get a red runbot due to a silly timeout than to sometime wait a bit longer than .1 second. 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#242214
This update resolves an issue where exporting pivot data resulted in an error when no data was available. The system now gracefully handles empty data requests by returning a standard error message, ensuring a smoother user experience and preventing unexpected application crashes. This improves data export reliability.
Original PR description
Currently an exception is generated when controlled `/web/pivot/export_xlsx' tries to export xlsx with empty data. `KeyError: 'title'` This PR resolves the issue by raising an `UnprocessableEntity` exception when empty data is provided. The resulting 422 response indicates that the server understood the request and its syntax, but cannot process it because the data is invalid. sentry-6321555617 Forward-Port-Of: odoo/odoo#241415
This update fixes an issue where Odoo incorrectly prioritized the contact name over the legal entity name when creating accounts from XML files. Following discussions with CHKL, the system now correctly prioritizes the legal entity name, ensuring accurate partner identification for accounting and billing processes. This improves data integrity and compliance.
Original PR description
When we create an account.move from an XML file, Odoo first searches for an existing partner via some values fetched with `_import_retrieve_partner_vals()`. Amongst those vals, the name can be fetched from either the `Contact:Name` or the `PartyLegalEntity:RegistrationName`. Currently, the contact name is prioritized over the legal entity name. After discussion with CHKL, this should be the opposite. Discord link: https://discord.com/channels/678381219515465750/694447009679147068/1457691361959608413 Related ticket: opw-5269360 Forward-Port-Of: odoo/odoo#242205 Forward-Port-Of: odoo/odoo#242037
This update corrects a visual inconsistency in the Odoo chatter interface. Previously, paragraphs added in the composer didn't maintain their bottom margin when posted to the chatter, leading to mismatched spacing. This change ensures that the spacing between messages in the chatter matches the composer and sent emails, improving the overall user experience.
Original PR description
Problem: When adding a paragraph in the composer and sending the message, the paragraph posted in the chatter has a `margin-bottom` of 0. Cause: Paragraphs in the chatter rendering override the default bottom margin, resulting in inconsistent spacing compared to the composer and the sent email. Solution: Update selector to only target the last `p`. Steps to reproduce: - Open the chatter composer. - Add a paragraph using "/Paragraph". - Add some text. - Send the message. - Observe that the message posted in the chatter has no bottom margin, unlike in the composer. opw-5378129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240082
This update fixes an issue where string values entered in the web_studio field editor were incorrectly displayed with extra quotes and slashes. Now, string values are correctly formatted and saved, ensuring accurate field configuration within the studio interface. This improves the reliability of data input and configuration.
Original PR description
Have a field widget with an option of type "string" (supportedOption meta field of the widget) In studio, change the value for that option. Before this commit, the value appeared in the input as escaped: there were supplementary quotes and slashes After this commit, the string value is correctly displayed. Forward-Port-Of: odoo/enterprise#103410 Forward-Port-Of: odoo/enterprise#103364
This update fixes an issue where refund alerts were triggered incorrectly due to rounding differences in order totals. The change ensures that the system accurately compares refund amounts to original order amounts, preventing false alerts and improving the reliability of the POS system. This ensures accurate financial reporting and reduces potential customer service issues.
Original PR description
Before this commit, if the total amount of the order had rounding differences compared to the sum of its lines, the system could incorrectly trigger an alert stating that the refund amount exceeds the original order amount. This was due to a direct comparison between the two amounts without considering potential rounding issues. opw-5402240 Forward-Port-Of: odoo/enterprise#102224
This update corrects a bug where changing a product's type (from goods to service) without a standard update could bypass inventory checks, leading to incorrect stock tracking. The fix ensures that a validation error is raised when a product's type is changed, maintaining accurate inventory management.
Original PR description
## Description of the issue/feature this PR addresses: `compute_is_storable` is called when the `type` value is modified but the `write` function is never called when the value is set using the…
## Description of the issue/feature this PR addresses: `compute_is_storable` is called when the `type` value is modified but the `write` function is never called when the value is set using the `is_storable` attribute. Updating `is_storable` using a `write` ensure that an exception is raised when move line exists. But this fix addresses the symptom, not the underlying issue. So why ? Is it related to the cache or unit test environment ? ## Current behavior before PR: In a Unit test, If you convert a consumable and storable product to a service, no exception is raised, even with existing stock moves. Unlike the previous version of Odoo (<15.0), where an exception was raised when the product type was changed and stock movements existed, detection now occurs if the ‘is_storable’ status is changed. However, this detection is not triggered if the value of ‘is_storable’ is defined by its attribute. ## Desired behavior after PR is merged: An exception must be raised (like Odoo 14.0) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239284
This update fixes an issue where tax names and invoice labels were displayed in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see accurate Vietnamese labels when using Odoo with Vietnamese chart of accounts, improving the user experience.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#241681 Forward-Port-Of: odoo/odoo#236502
This update prevents unnecessary email reminders for timesheet approvals. It ensures reminders are only sent when there are actual timesheets needing review, and when a user is correctly designated as a manager or approver. This reduces email clutter and improves the efficiency of the approval process.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#102785 Forward-Port-Of: odoo/enterprise#52355
This update resolves an issue where grouped Kanban cards were displaying incorrectly due to a change in the Kanban templates. The team removed a specific CSS class that was no longer needed, restoring the correct card heights and overall display. This ensures a consistent and professional user experience.
Original PR description
Since commit https://github.com/odoo/enterprise/pull/70460 and the reworking of the Kanban templates, the h-100 class was no longer correct. This PR fixes the issue by removing this class. task-5439265 Forward-Port-Of: odoo/enterprise#102801
This update fixes an issue where inline code blocks were difficult to remove, particularly at the end of lists. The changes ensure that code styles disappear correctly when the last character of inline code is deleted, enhancing the editor's usability. This improves the user experience when editing text with code snippets.
Original PR description
Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140 Forward-Port-Of: odoo/odoo#238552
This update resolves an issue where the 'leitweg-id' field in xRechnung invoices was incorrectly formatted during the forward port. The fix involved updating a helper function to ensure accurate mapping of this identifier, preventing potential invoice processing errors. This ensures compliance with German e-invoice regulations.
Original PR description
Correction of the forward port for the leitweg-id in the 'cbc:BuyerReference' field for the xRechnung invoice. The 'export_invoice_vals' function is an old helper that is not used by default anymore (but used by the tests, that is why the tests did not catch the error). I added the if statement in the corresponding new helper: '_add_invoice_header_nodes' and changed the test for it to catch the error. Related: #236333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241982
This update fixes an issue where rental transfer dates weren't automatically adjusted when a rental order's period was extended. The fix mirrors the rescheduling behavior of purchase orders, ensuring rental transfers are updated accurately, improving the rental process for customers. This prevents scheduling discrepancies and ensures accurate transfer management.
Original PR description
### Steps to reproduce: - In the settings enable "Rental Transfers" - Create a storable and rentable product P - Create and confirm a rental order for 1 unit of P - Change the rental period to 10 days in the future #### > The rental tranfers were not updated accordingly ### Cause of the issue: Nothing is currently implemented to reschedule the rental transfers. ### Fix: We somewhat mimic the reschedule purchase behavior: https://github.com/odoo/odoo/blob/6ca34a0f5347e0611cde95453119dda8b40fa589/addons/purchase_stock/models/purchase_order_line.py#L98-L101 But we rely on the order itself rather than its order lines since the `start_date` and the `return_date` are related fields so that no `write` is triggered when the order is rescheduled: https://github.com/odoo/enterprise/blob/96a80f583a0ca502ff06bc05d03775c76c6a7537/sale_renting/models/sale_order_line.py#L18-L19 opw-5158508 Forward-Port-Of: odoo/enterprise#101334
This update corrects a problem where invoice XML files generated for Danish Nemhandel transactions were failing validation due to an incorrect assumption about the 'PrepaidAmount' field. The fix ensures the 'PrepaidAmount' node is only removed when the value is actually zero, resolving the validation issue and allowing invoices to be correctly processed.
Original PR description
To reproduce: create an invoice that is reconciled (typically a credit note) before Send&Print. Check the validity of the xml with a schematron => it fails due to the value of the PrepaidAmount The node PrepaidAmount gets removed because it was wrongly thought to be always empty. We now only remove it if the value is at 0. 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#242008
This update resolves a technical issue related to how the system acknowledges PEPPOL messages. Previously, continuous acknowledgments caused problems on the IAP side, leading to errors. This fix ensures acknowledgments happen after the main processing loop, improving system stability and reliability.
Original PR description
The acknowledgment should not happen in the loop, but after. In a case a problem happened in the loop, it's acceptable that we end up not acknowledging messages, their status will be retrieved again at the next call. At the moment those continuous acks cause serialization issues on IAP side. task-none Forward-Port-Of: odoo/odoo#242187
A validation error prevented users from creating new spreadsheet templates within the Quality Control app. This update adds a default name to the template, resolving the validation issue and allowing users to successfully create and utilize these templates. This ensures consistent and reliable spreadsheet creation for quality control processes.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671
12 changes
Resolved issues and error corrections
This update ensures the live chat info panel remembers your preference (open or closed) across different chat sessions. Previously, the panel always opened by default, leading to a frustrating experience. Now, the panel will automatically adjust to your last setting, improving ease of use.
Original PR description
**Purpose of this PR:** Previously, the livechat info panel would always open by default when switching between chats, regardless of the user's preference. This required users to manually close the panel repeatedly. This commit persists the panel's toggle state, so the panel remains open or closed based on the user's last choice across all livechat sessions. Task-5291258 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241917 Forward-Port-Of: odoo/odoo#238472
This update resolves an issue where tax grouping keys in the account_edi_ubl module could sometimes be unexpectedly empty. This fix ensures accurate tax calculations and reporting, particularly when using customizations. A minor correction was also made regarding excise taxes to improve data accuracy.
Original PR description
Some overrides assign a value to the tax's grouping_key after the super call. However, the returned value could be None. Also fix a little mistake regarding excise taxes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239959 Forward-Port-Of: odoo/odoo#239954
This update resolves an issue where users were encountering an error when previewing XML files containing embedded PDFs. The fix ensures that thumbnails are only generated for valid PDF files, preventing the 'Invalid Operation' error and improving the user experience when working with documents.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Upload an XML file that contains an embedded PDF in base64. 3. Click on the `Info & Tags` icon on the top right in the Documents kanban view 4. Open the imported XML file Issue: - An `Invalid Operation: Only PDF files can have thumbnail` error occurs. Cause: - The `Attachment` model attempts to generate a thumbnail for the XML file because it contains PDF data. However, as of now, thumbnails are only generated for valid PDFs, so the `generatePdfThumbnail` function returns `isPdfValid: false` but `setPdfThumbnail` method fails to handle this `false` value in resulting invalid rpc call. Solution: - Update the condition in `setPdfThumbnail` to consider only valid PDFs. File: [Link](https://drive.google.com/file/d/19OxVJeqj9i-VgH9D6Aqk0P9Tuf6zlPwB/view?usp=sharing) opw-5374529 Forward-Port-Of: odoo/odoo#240546
This update adjusts a timeout setting in the SMTPD tests, preventing unnecessary test failures. Previously, a short delay caused tests to fail frequently, triggering alerts. Now, the tests have more flexibility to complete without being disrupted by overly strict time limits, improving overall system reliability.
Original PR description
There are multiple cases where the SMTPD tests fail due to a timeout error. It is much worse to get a red runbot due to a silly timeout than to sometime wait a bit longer than .1 second. 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#242214
A bug preventing users from searching within sign templates has been fixed. Previously, the search function within PDF templates was unresponsive. This update removes a technical issue that blocked users from utilizing the search feature, ensuring they can efficiently locate information within sign templates.
Original PR description
Currently when the user is viewing sign templates, they are unable to search within a PDF. **Steps to replicate:** * Install `sign` with demo data * Sign > Templates > Open a template * Try searching using the magnifying glass button **Observed Behavior:** * User is unable to type anything in the PDF search box. **Root cause:** * This error happens because `preventDefault()` is called during a `keydown` event. At [1], calling `event.preventDefault()` stops the key’s normal behavior, so the typed character is not added to the input field. **Solution:** * Remove the `preventDefault` call which allows the search to work again. [1]: https://github.com/odoo/enterprise/blob/3df585779e6ede664279331c4531043688dadf17/sign/static/src/backend_components/editable_pdf_iframe_mixin.js#L623 opw-5366074 Forward-Port-Of: odoo/enterprise#102749
This update fixes a technical issue that caused a traceback to appear when canceling orders with the 'Takeout or Delivery' preset. The fix redirects users to the correct screen and prevents new orders from being created during the cancellation process, improving the user experience.
Original PR description
### step to reproduce: - Set default preset to "Takeout or Delivery" in restaurant config. - Open restaurant . - Open any table and add a product. - Cancel the order using the action button. ### issue: - A popup appears asking to select a partner/floating order name, followed by a traceback. ### cause: - Traceback occures as next screen is loaded after order deletion. ### fix: - Redirect to the default screen before deleting the order. - Ensure that no new order is created when the next screen is the floor screen. task: 5092951 Forward-Port-Of: odoo/odoo#242199 Forward-Port-Of: odoo/odoo#227925
This update enhances the HTML Builder by automatically updating container information (like titles and buttons) when the editing element changes. This ensures a more responsive and accurate builder experience. The change also resolves a previous issue identified in PR #239235.
Original PR description
After the [refactoring of html_builder], the container's information was computed directly in the plugin. This change ensures that containers fields (title, header buttons, isDisabled, etc.) are updated automatically when the editing element changes, using dom state. This change also fixes an issue addressed in PR #239235. [refactoring of html_builder]: https://github.com/odoo/odoo/commit/9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 Related to task 5391316.
This update fixes an issue where iOS devices were not displaying the website's favicon when creating shortcuts. The change adds a specific HTML tag to ensure the correct icon is shown, improving the user experience on iOS PWA devices. This ensures a more professional and consistent brand appearance.
Original PR description
iOS devices currently display the first letter of the website name instead of a favicon when creating a shortcut. This commit adds the `apple-touch-icon` link tag referencing the favicon to ensure the icon displays correctly. task-5427275
This update resolves a random error that occasionally occurred during the project task tour. The fix utilizes a more specific trigger to ensure the tour initiates reliably, improving the user experience. This ensures consistent and accurate tour functionality.
Original PR description
Fix this random error in the tour by using a more precise trigger. runbot-error-id~234373 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 delivery slips were printing move lines in the wrong order, primarily when multiple products were included in a single delivery. The fix ensures that move lines are printed in the same order as their associated stock moves, resulting in accurate and consistent delivery slip reports. This improves the reliability of our inventory tracking process.
Original PR description
**Steps to reproduce:** - Add 2 products in a delivery - Add the second's product move lines before the first one. - Validate and print delivery slip **Issue:** We iterate the `move_line_ids` directly which means if we have a new move line for a move with a lower id, it will push the product to the end of the delivery slip. **Example:** If we have `stock.move(1,)` with `stock.move_line(52,)` and `stock.move(2,)` with `stock.move_line(51,)`. `stock.move_line(51,)` will be printed first, which introduces a change in the order of the delivery slip. **Fix:** Iterate on `move_ids` and access `move_line_ids` through it, to print `move_lines_ids` in the same order of the `move_id`. Task: 4570203 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242166 Forward-Port-Of: odoo/odoo#213400
This update corrects a discrepancy in the calculation of Belgian withholding taxes within the Odoo Enterprise system. The changes ensure that tax rates and regulations up to 2026 are accurately reflected, improving payroll accuracy for businesses operating in Belgium. This is a critical fix to maintain compliance with Belgian tax laws.
Original PR description
TaskID: 5403525 Forward-Port-Of: odoo/enterprise#103271 Forward-Port-Of: odoo/enterprise#103215
This update resolves an issue where a website tour feature timed out during testing, specifically when searching for products. The fix ensures the tour waits for the dropdown to populate before initiating a search, preventing unnecessary clicks and ensuring a smoother user experience. The `searchNeeded` parameter has been removed as it was no longer required.
Original PR description
__Behavior before commit:__ When `searchNeeded` is `true`, `changeOptionInPopover` adds a step to search the option in the dropdown. This step is not working if the dropdown is not ready. This causes `add_to_cart_snippet_tour` to timeout when the tests are run with demo data because the products created in the python side of the test are not showing directly. If the demo data are not included and `searchNeeded` is `true`, it is useless to search. Furthermore in this case, it might click on the item before the search request is finished. The popover will then be kept open when the request end (without result because the search will exclude the already selected item). __Fix:__ - Wait for the dropdown to be ready by waiting for the items to appear in the dropwdown. Then only make the search if the item isn't already in the list. - Remove the now useless `searchNeeded` parameter runbot-234680 Forward-Port-Of: odoo/odoo#242312 Forward-Port-Of: odoo/odoo#240193
6 changes
Resolved issues and error corrections
This update resolves an issue where changes to spreadsheets were lost when users disconnected during message sending. The fix ensures that messages are automatically retried until successfully sent, preventing data loss and improving the reliability of collaborative spreadsheet editing. This enhances the overall user experience and data integrity.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116
This update resolves a previous issue where tests for the account_reports_cash_basis module were not running, leading to undetected errors. By adding a test execution step, we now ensure that all changes to this module are thoroughly tested before being released, preventing future problems and maintaining report accuracy.
Original PR description
The account_reports_cash_basis module was previously blacklisted on Runbot, causing its test suite to be bypassed during CI. Consequently, several regressions remained undetected (notably Runbot error 234873). This commit adds the `post_install_l10n` tag to ensure tests are executed prior to merging, preventing future regressions in this module. -------------------------------------------------------------- A previous change (see https://github.com/odoo/enterprise/commit/eba96e1f976b953fb8056249ea494e8f06e3c668) modified the reporting logic for Unaffected Earnings. Some cash basis test scenarios were not updated in the initial PR, leading to assertion failures. This commit updates the expected test values to match the current reporting format. runbot-234873
This update resolves an issue where long date ranges in Field Service tasks caused the kanban card layout to break. The fix ensures the date range widget stays within the card's boundaries, maintaining a consistent and visually appealing user experience. This prevents visual disruptions and improves usability.
Original PR description
Steps to reproduce: ---------------------------- 1. Install Field Service module 2. Open any task from Field service module 3. In the Planned date field set a wide range spanning years, for example:…
Steps to reproduce: ---------------------------- 1. Install Field Service module 2. Open any task from Field service module 3. In the Planned date field set a wide range spanning years, for example: Dec 16, 2024, 1:30 PM → Oct 13, 2026, 6:00 PM. 4. Go back to kanban view 5. Adjust display to around 360 px Observation: ---------------------------- The planned date daterange widget overflows and extends outside the kanban card, breaking the card layout and visual containment. Issue: ---------------------------- The daterange widget's parent container did not enforce a width, so the widget could grow beyond the kanban card boundary when a long date range was used. Solution: ---------------------------- Add the w-100 class to the daterange container div to enforce full-width layout within the kanban card. Before: <img width="584" height="529" alt="before_css" src="https://github.com/user-attachments/assets/e89302b0-975c-47eb-91ec-89dbfe813493" /> After: <img width="561" height="528" alt="after_css" src="https://github.com/user-attachments/assets/48b60a78-18da-4504-98ef-a9c4013b107b" /> opw-5219941
This update corrects inconsistencies in the documentation across several Odoo modules. The changes ensure that all public documentation is clear, accurate, and follows established standards. This improves the usability and maintainability of the system for internal teams.
This update fixes a bug that caused data loss when the spreadsheet system encountered errors during message sending, particularly during user disconnections. The fix ensures messages are retried until successfully sent, preventing lost changes and improving overall spreadsheet stability. This enhances the user experience and data integrity.
Original PR description
If, for any reason, the sending of a revision creates an error b.e. when the user is disconnected, we never reset the "waitingForAck" flag, and all future messages will be queued but never send. The result of this behavior was that any user action during any disconnection will set the spreadsheet in a state where all changes from that point are lost. This fix handles the error while sending a message and always reset the flag, so that at next change, we will try to re-send the same message until it works. Task: 5469116
This update resolves a validation error that occurred when creating new spreadsheet templates within the Quality Control app. The fix provides a default name for the template, ensuring the creation process completes successfully. This improves usability for users creating quality control spreadsheets.
Original PR description
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control…
**Issue** A validation error is raised when creating a new spreadsheet template from a Quality Control Point. **Steps to reproduce** 1. Open the Quality app. 2. Go to Quality Control > Control Points. 3. Click "New". 4. Set the type to "Spreadsheet". 5. Click on Spreadsheet Template > Search More. 6. Click "New". -> A validation error is raised. **Cause** In `quality_view`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/quality_control/views/quality_views.xml#L840C17-L845C19 the `many2one_spreadsheet` widget (see [`many2one_spreadsheet_field.js`](https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L36)) overrides "Create and Edit" to create a new spreadsheet through `Many2XSpreadsheetAutocomplete`: https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/spreadsheet_edition/static/src/assets/components/many2one_spreadsheet_field.js#L11C9-L14C51 This flow does not set a default value for the required `name` field, nor does `action_open_new_spreadsheet`:https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/spreadsheet_edition/models/spreadsheet_mixin.py#L348 Since `name` is required: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/quality_control/models/quality_spreadsheet_template.py#L12 validation fails. **Solution** Provide a default value for the `name` field, using the same default as in `documents_document.py`: https://github.com/odoo/enterprise/blob/8365feab396679f0323e89c2f4e0c825a0b2ee7e/documents_spreadsheet/models/documents_document.py#L321 opw-5340710 Forward-Port-Of: odoo/enterprise#101671
8 changes
Resolved issues and error corrections
This update resolves a random error in how Odoo validates financial formulas. Previously, the validation process could incorrectly flag correct formulas as invalid due to an issue with how tokens were processed. Sorting the tokens ensures a consistent and accurate check, guaranteeing that formulas are always correctly evaluated.
Original PR description
…me tokens greedily Fixes issue https://github.com/odoo/odoo/issues/241004 Description of the issue/feature this PR addresses: This is a hard to reproduce bug becase it depends in what order the set…
…me tokens greedily Fixes issue https://github.com/odoo/odoo/issues/241004 Description of the issue/feature this PR addresses: This is a hard to reproduce bug becase it depends in what order the set is iterated. Since the set is an unordered structure, this bug will happen just sometimes. The issue is this: The _check_formula in this module iterates over tokens to check if the formula only includes allowed tokens or numbers. This check passes when the set is iterated in a way that the token '>=' appears before the '>' token. But if it is the other way around, the check fails. This is because the way the tokens are consumed in the for; if the '>' is before the '>=', the '>' token will be consumed, the position will be advance one position forward and the next character found will be just the '=' character. This is not an allowed token and the check fails. The way to solve this is to sort the set by length of the token, from longest to shortest. This assures a greedy consumption of token, which is what is needed to avoid this bug. Current behavior before PR: The _check_formula randomly marks a correct formula as malformed Desired behavior after PR is merged: Using >= or <= should never cause a formula to be marked as malformed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A technical issue was causing an error when processing large SEPA credit transfers. This update corrects a misinterpretation of the maximum payment amount, ensuring payments up to €9,999,999.99 are processed correctly. This resolves a potential disruption to financial transactions.
Original PR description
**Steps to reproduce:** - Create a vendor payment with the amount 88888888.88 in euros - Set the payment method to SEPA Credit Transfer - Create a vendor batch paymentand set its payment method to SEPA Credit Transfer - Add the created payment to the batch payment - Validate the batch payment **Issue:** An error message pops up, indicating that the payment amount exceeds the maximum amount 99999999.99 for payments in Euros. This not the case since 88888888.88 < 99999999.99 **Solution:** Make sure the number of digits in the payment amount is strictly greater than the max digits instead of greater than or equal opw-5428415 Forward-Port-Of: odoo/enterprise#103349
This update fixes an issue where invoices could incorrectly retain accounts from their original company after changing the invoice's company and journal. The fix ensures that invoices accurately reflect the correct company and account when switching company branches. This prevents posting errors and maintains financial accuracy.
Original PR description
This issue was already fixed in this PR: https://github.com/odoo/odoo/pull/234357 But that was revert because there was a bug with company branches ### Steps to reproduce: - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A - On the same invoice, change the company to Company B and change the journal to a journal of Company B - Save, then confirm the invoice. ### Issue: The invoice, now belonging to Company B, still has the same account from company A, and we are able to post it on the journal from company B opw-5167958
This update streamlines how Odoo handles database changes, preventing potential issues where pre-commit hooks needed manual flushing. By letting the ORM manage flushing automatically, this change enhances database stability and reduces the risk of errors. This aligns with our ongoing efforts to improve Odoo's reliability.
Original PR description
In the existing implementation sometimes precommit hooks need to flush manually because they are ran after the flush is executed in the cursor. A precommit that triggers ORM changes may be not flushed unless it is done explicitly, however an explicit call may turn into an infinite loop. This removes the need to flush in precommit hooks and let the ORM handle it safely. Flushing of the environment was already done in #220379. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug where archived products could be accidentally sold through combo orders in the Point of Sale (PoS) system. Now, archived products are automatically excluded from combos, ensuring accurate inventory and preventing incorrect sales. This improves the reliability of PoS operations.
Original PR description
Before this commit, when a product used in a combo was archived, it was still possible to sell it through the combo in the PoS. After this commit, archived products are excluded from combos, preventing them from being sold inadvertently. opw-5180301 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233930
This pull request addresses visual issues in the website editor, specifically preventing blurry countdown canvases and text overlap with icons. The changes ensure a sharper, more reliable experience for users when editing website content, particularly with countdown timers and image snippets.
Original PR description
## [FIX] website: prevent blurry countdown canvas and text on zoom [Commit 1] Steps to reproduce: - Go to Website -> Edit Mode - Add a Countdown snippet (size: "Small") - Save and zoom in/out, the countdown canvas and text appears blurry The countdown was rendered at a low resolution, which caused it to blur when zooming. This fix updates the canvas to draw at the proper resolution so the countdown remains sharp at any zoom level. ## [FIX] web_editor: prevent text overlap with icon [Commit 2] Steps to reproduce: - Go to Website -> Edit Mode - Add a Image snippet - Enter a long text in search bar: Issue: 1. Text overlaps with search icon. 2. Selecting the "Photos (via Unsplash)" option causes the text to overlap the dropdown icon. The fix adjusts the end padding to provide sufficient spacing between the text and the icons. task-[4771268](https://www.odoo.com/odoo/project/974/tasks/4771268) Forward-Port-Of: odoo/odoo#213373
This update resolves a visual inconsistency in Odoo reports. Previously, long company taglines would push the address off-screen when generating PDFs, leading to a mismatch between the preview and the final printed report. Adding a width constraint ensures taglines wrap correctly, maintaining a consistent and professional report layout.
Original PR description
In the report when a company_tagline is long it offsets the address outside of the visible area but only in PDF. This creates a mismatch between the preview and the PDF rendering, creating unpredictable behavior. Adding a width ensures the tagline wraps instead of pushing the address out. task-5367661 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a warning message that appeared during payment token searches. The change adds a field to the payment token model to ensure accurate searching by name, preventing the warning and improving the stability of the payment processing system. This ensures consistent and reliable search functionality.
Original PR description
address this warning: `2026-01-07 04:53:23,985 3407309 WARNING v18c_... odoo.models: Cannot search on display_name, no _rec_name or _rec_names_search defined on payment.token`
5 changes
Resolved issues and error corrections
This update resolves an issue where user avatars in the Chat UI were appearing distorted due to incorrect image scaling. The fix applies the 'object-fit: cover' style, ensuring avatars are displayed correctly and consistently. This improves the user experience by presenting accurate and properly sized profile pictures.
Original PR description
Before this commit, user avatars in the Chater UI were not displayed using the object-fit: cover style, causing distorted or improperly scaled images. Current behavior before PR: <img width="671" height="380" alt="image" src="https://github.com/user-attachments/assets/a4b7ef3a-0c69-4fec-bf2a-70c9bd89236e" /> Desired behavior after PR is merged: <img width="663" height="384" alt="image" src="https://github.com/user-attachments/assets/479586c8-a01c-45fb-9e46-9246616e1329" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A recent issue in the Odoo Enterprise system's tour testing process was causing tests to incorrectly finish before manufacturing orders were fully processed. This update adds a step to ensure notifications are cleared, preventing the tour from prematurely concluding and ensuring accurate test results.
Original PR description
The tour test `test_barcode_production_create_bom` could fail when Odoo executes the second manufacturing order too quickly. If the validation notification from the first manufacturing order is still visible, the tour incorrectly considers the test finished while the MO is not fully processed. This change adds a step to explicitly close the notification before starting the new manufacturing order. Issue observed in Runbot build 248089 (v17).
This update ensures the mail plugin correctly identifies the version of Odoo being used. Previously, a recent update caused compatibility issues with older Odoo versions. Now, the plugin will display a message if it doesn't support the current Odoo version, preventing unexpected errors.
Original PR description
Purpose ======= Backport of https://github.com/odoo/odoo/commit/f1bc56523875f1f9c55dd33b575063f67ac192ee The new addin has been refactored and doesn't work with older Odoo version, and so we add an endpoint to be able to show a message if we don't support that Odoo version. Task-4727609 Forward-Port-Of: odoo/odoo#238811
This update addresses several minor issues within the spreadsheet component of Odoo. It includes fixes for data validation and improvements to the user interface, specifically related to popover behavior. These changes enhance the overall spreadsheet functionality and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd315c8d5d [REL] 17.0.83 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bd315c8d5d [REL] 17.0.83 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/6e91764cda [REV] grid: close popovers on external clicks [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/df7c781aa3 [REL] 17.0.82 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/45a24fdf1e [FIX] grid: close popovers on external clicks [Task: 5418367](https://www.odoo.com/odoo/2328/tasks/5418367) https://github.com/odoo/o-spreadsheet/commit/05e6ca5026 [FIX] data validation: fix date criterion [Task: 5343580](https://www.odoo.com/odoo/2328/tasks/5343580) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue in the 17.0 version of Odoo where tax names for cashback taxes were inaccurate. The changes rename relevant fields and add Portuguese translations to ensure accurate reporting and compliance with Brazilian tax regulations. This improves the clarity and reliability of financial data.
Original PR description
In 17.0, some taxes have had their incorrect name for the cashback taxes. This renames the invoice_label and name fields of such taxes to better represent what they are as well as add portuguese translations where necessary. task-5470453