Daily updates from Odoo
Navigate
Branch
Saturday, January 3, 2026
33 changes
7 changes
Enhancements to existing features
This update adds a helpful link within the Accounting Settings to Odoo's documentation on Deferred Expenses and Revenue management. This allows users to quickly access detailed information and best practices for managing these important accounting concepts, improving accuracy and understanding.
Original PR description
In the Accounting Settings, add a "?" icon that points at the Odoo documentation on Deferred Expenses and Revenue management. task-5418388 Forward-Port-Of: odoo/enterprise#103090
Resolved issues and error corrections
This update fixes a crash that occurred when switching tabs while a receipt was being printed in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing the printing process from failing. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#241781 Forward-Port-Of: odoo/odoo#239008
This update resolves an issue where submitting a forum post with an empty description would cause a server error. The fix resets a key setting to prevent a problematic form submission process. Users can now successfully post questions with descriptions.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid.…
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 5. Now add a description. 6. Post Your Question. => Error page: Bad Request 7. Go back or open any forum page => Will receive error on each page until you clear sessionStorage Technical ============ The commit [1] updates the website forum interaction to use the html_editor `Wysiwyg` instead of `loadWysiwygFromTextarea`. The textarea is hidden and populated through `WebsiteForumWysiwyg`. When the description is left empty and the form is submitted, `WebsiteForumWysiwyg.onSubmitButtonClick` populates empty content into the textarea, sets the `readyToSubmit` property to true, and resubmits the form to trigger the interaction logic. The editor container is then validated as empty, marked invalid, and the submission is prevented. After the description is refilled and the form is submitted again, the `readyToSubmit` is already true, causing an early return from `onSubmitButtonClick`. This skips populating the textarea from the editor container. Since validation is performed against the editor container, the form is submitted successfully. As we use form action that relies on named inputs, including the hidden textarea, the submitted payload contains an empty textarea value. As a result, the request fails with a bad request error due to empty content. [1] https://github.com/odoo/odoo/commit/6bd3d1b557f82475f0a78ef8ff0529528e5f2b29 After this commit ====================== This commit fix the issue by resetting `readyToSubmit` property to false. Task-5400394 Forward-Port-Of: odoo/odoo#241544
This update corrects a bug in the forum post form where fields were incorrectly marked as invalid, even after being filled in. The change, triggered by a refactoring of user interactions, now properly highlights invalid fields, ensuring users receive accurate feedback when creating forum posts. This improves the overall user experience and data integrity.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 6. Now add a description. 7. Post Your Question. => Both the title and description are marked as invalid, yet form is submitted successfully. After commit [1], refactoring public widgets to Interactions, the `is-invalid` class toggle for forum post title and description used an incorrect condition, leading to improper highlighting of these fields. [1] https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Task-5400394 Forward-Port-Of: odoo/odoo#241540
This update resolves an issue where the 'Jump to Present' button in non-aside chatters was unreliable, causing flickering and incorrect scrolling. By disabling a browser feature that interfered with scrolling, this fix ensures users can reliably access the latest messages in chatters.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the…
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the view flickered and the scroll position jumped back, preventing users from reaching the latest message. This happened because the browser’s native scroll anchoring interfered with the scroll-to-bottom behavior when messages were reloaded. **Current behavior before PR:** --------------------------------- - In non-aside chatter, clicking **Jump to Present** caused flickering. - The view jumped back instead of staying on the latest message. - Users could not reliably reach the most recent messages. **Desired behavior after PR is merged:** ----------------------------------------- - Clicking **Jump to Present** in non-aside chatter scrolls directly to the latest message without flickering. - The scroll position remains stable and does not jump back. - The **Jump to Present** button works consistently. **Task:** 5264332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240934
This update corrects a previous development step that missed incorporating essential QR and payment details into invoices. The fix ensures accurate invoice generation and compliance with local regulations, improving the accuracy of financial reporting. This resolves issues reported in OPW-5385872 and OPW-5414922.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
This update fixes an issue where the left pane in the Point of Sale interface was sometimes obscured by its right-hand content, making text difficult to read. The fix ensures the left pane maintains its intended width, improving the user experience. The problem was intermittent and resolved by adjusting the layout's flexibility.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359 Forward-Port-Of: odoo/odoo#241941 Forward-Port-Of: odoo/odoo#241731
4 changes
Resolved issues and error corrections
This update fixes a crash that occurred when users switched tabs while a receipt was being printed in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing the printing process from failing. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#241781 Forward-Port-Of: odoo/odoo#239008
This update corrects a bug in the forum post form where invalid fields (like a missing title) were not properly highlighted, allowing users to submit incomplete posts. The fix ensures that required fields are correctly marked as invalid, improving the user experience and data integrity within the forum.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 6. Now add a description. 7. Post Your Question. => Both the title and description are marked as invalid, yet form is submitted successfully. After commit [1], refactoring public widgets to Interactions, the `is-invalid` class toggle for forum post title and description used an incorrect condition, leading to improper highlighting of these fields. [1] https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Task-5400394 Forward-Port-Of: odoo/odoo#241540
This update corrects a technical issue where QR and payment details were missing from invoices. The team has extended the existing view to include these crucial elements, ensuring accurate reporting and compliance. This resolves issues OPW-5385872 and OPW-5414922.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
This update fixes a visual issue in the Point of Sale interface where the left-hand product pane would sometimes shrink, making text unreadable. The fix ensures the pane maintains its intended width, improving the user experience. The issue was intermittent and related to how the layout elements interacted within the flex container.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359 Forward-Port-Of: odoo/odoo#241941 Forward-Port-Of: odoo/odoo#241731
4 changes
Resolved issues and error corrections
This update fixes a crash that occurred when users switched tabs while a receipt was being printed in Point of Sale. The fix ensures the receipt component is reliably loaded and accessible, preventing errors and guaranteeing receipt printing completes successfully. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#241781 Forward-Port-Of: odoo/odoo#239008
This update corrects an issue where the forum post form wasn't properly validating the title and description fields, leading to a misleading 'invalid' message despite successful submission. The fix ensures that the form correctly highlights invalid fields, improving the user experience and data integrity within the forum.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 6. Now add a description. 7. Post Your Question. => Both the title and description are marked as invalid, yet form is submitted successfully. After commit [1], refactoring public widgets to Interactions, the `is-invalid` class toggle for forum post title and description used an incorrect condition, leading to improper highlighting of these fields. [1] https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Task-5400394 Forward-Port-Of: odoo/odoo#241540
This update corrects a technical issue where QR and payment details were missing from invoices. The fix ensures accurate reporting and compliance with local regulations, specifically addressing issues OPW-5385872 and OPW-5414922. It improves the accuracy of invoice data.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
This update fixes a visual issue where the product selection pane in the Point of Sale interface was sometimes shrinking too small, making text difficult to read. The fix ensures the pane maintains its intended width, improving the user experience. The problem was intermittent and related to how the interface elements were arranged.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359 Forward-Port-Of: odoo/odoo#241941 Forward-Port-Of: odoo/odoo#241731
3 changes
Resolved issues and error corrections
This update fixes an issue where the product screen's left pane would sometimes shrink, making text unreadable for users. The fix prevents the left pane from being pushed by its right sibling, ensuring consistent readability across devices. This improves the user experience for point-of-sale transactions.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359 Forward-Port-Of: odoo/odoo#241731
This update corrects a minor issue in the account_edi_ubl_cii module, ensuring that invoice XML files now accurately use the commercial partner's name instead of the invoice address name. This change aligns with a recent update in Odoo's standard XML generation process, improving data consistency and accuracy for UBL invoices.
Original PR description
The dict-to-xml helpers were still using `partner.display_name` which includes the 'Invoice address' suffix. Changed to use `partner.commercial_partner_id.display_name` when partner name is not available, to match the fix in https://github.com/odoo/odoo/pull/232819 for the standard XML generation. task-4614564 Forward-Port-Of: odoo/odoo#241250
This update corrects a technical issue where QR and payment details were missing from invoices in the l10n_co_edi module. The fix ensures accurate invoice generation and reporting for Colombian businesses, aligning with local tax regulations. This resolves previous issues reported as OPW-5385872 and OPW-5414922.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
9 changes
Enhancements to existing features
This update adds a helpful link within the Accounting Settings to Odoo's documentation on Deferred Expenses and Revenue management. This provides users with immediate access to detailed information and best practices for handling these financial items, improving clarity and accuracy.
Original PR description
In the Accounting Settings, add a "?" icon that points at the Odoo documentation on Deferred Expenses and Revenue management. task-5418388 Forward-Port-Of: odoo/enterprise#103090
Resolved issues and error corrections
This update fixes an issue where the displayed price in the Point of Sale system was incorrectly showing the total price instead of the unit price. The fix ensures that the correct unit price is shown when manually adjusting prices using the numpad, improving accuracy for sales transactions. This change was made to align with the expected user experience.
Original PR description
Steps to reproduce ------------------ 1. Insall `l10n_fr_pos_cert` and set the company to the french one 2. Open PoS, and select a product, it will have a price say X 3. Using the numpad, change the price of that product to Y Observe that the line now says "Old price unit: Y * Qty / Unit", instead of it being "X / Unit". Why it's happening: ------------------- We were displaying the `currencyDisplayPrice`, which is the total amount to be paid, instead. The fix ------- We add a getter on the product model `displayPriceUnit`, it shows the original product unit price. We therefore introduce a new getter that compute the unit price using the original lst price. opw-5365735 opw-5378158 Forward-Port-Of: odoo/odoo#241437 Forward-Port-Of: odoo/odoo#238135
This update fixes a crash that occurred when users switched tabs while a receipt was being printed in Point of Sale. The change ensures the receipt component is reliably loaded and accessible, even during tab transitions, preventing printing failures. This improves the overall reliability of the PoS system.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#241781 Forward-Port-Of: odoo/odoo#239008
A bug was causing a "Bad Request" error when submitting forum posts with an empty description. This update corrects the forum submission process, ensuring posts with descriptions are properly validated and submitted. The fix resets a key flag to prevent incorrect form processing.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid.…
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 5. Now add a description. 6. Post Your Question. => Error page: Bad Request 7. Go back or open any forum page => Will receive error on each page until you clear sessionStorage Technical ============ The commit [1] updates the website forum interaction to use the html_editor `Wysiwyg` instead of `loadWysiwygFromTextarea`. The textarea is hidden and populated through `WebsiteForumWysiwyg`. When the description is left empty and the form is submitted, `WebsiteForumWysiwyg.onSubmitButtonClick` populates empty content into the textarea, sets the `readyToSubmit` property to true, and resubmits the form to trigger the interaction logic. The editor container is then validated as empty, marked invalid, and the submission is prevented. After the description is refilled and the form is submitted again, the `readyToSubmit` is already true, causing an early return from `onSubmitButtonClick`. This skips populating the textarea from the editor container. Since validation is performed against the editor container, the form is submitted successfully. As we use form action that relies on named inputs, including the hidden textarea, the submitted payload contains an empty textarea value. As a result, the request fails with a bad request error due to empty content. [1] https://github.com/odoo/odoo/commit/6bd3d1b557f82475f0a78ef8ff0529528e5f2b29 After this commit ====================== This commit fix the issue by resetting `readyToSubmit` property to false. Task-5400394 Forward-Port-Of: odoo/odoo#241544
This update corrects a bug in the forum post form where invalid fields (title or description) were not correctly highlighted, allowing users to submit incomplete posts. The change was triggered by a refactoring of the forum's user interface. This fix ensures that users receive proper feedback when they attempt to submit a forum post with missing information, improving the user experience and data integrity.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 6. Now add a description. 7. Post Your Question. => Both the title and description are marked as invalid, yet form is submitted successfully. After commit [1], refactoring public widgets to Interactions, the `is-invalid` class toggle for forum post title and description used an incorrect condition, leading to improper highlighting of these fields. [1] https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Task-5400394 Forward-Port-Of: odoo/odoo#241540
This update fixes an issue where the 'Jump to Present' button in non-aside chatter was unreliable, causing flickering and incorrect scrolling. By disabling a browser feature that interfered with scrolling, this change ensures the button consistently takes users directly to the latest message.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the…
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the view flickered and the scroll position jumped back, preventing users from reaching the latest message. This happened because the browser’s native scroll anchoring interfered with the scroll-to-bottom behavior when messages were reloaded. **Current behavior before PR:** --------------------------------- - In non-aside chatter, clicking **Jump to Present** caused flickering. - The view jumped back instead of staying on the latest message. - Users could not reliably reach the most recent messages. **Desired behavior after PR is merged:** ----------------------------------------- - Clicking **Jump to Present** in non-aside chatter scrolls directly to the latest message without flickering. - The scroll position remains stable and does not jump back. - The **Jump to Present** button works consistently. **Task:** 5264332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240934
This update fixes a frustrating user experience where the invite dialog remained open after creating a group chat from a direct message. Now, the dialog automatically closes, providing a cleaner and more intuitive flow when creating and joining group chats. This improves usability and prevents confusion.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ When creating a group chat from a Direct Message via the invite dialog, the invite dialog remained open after the group chat was created. This resulted in a confusing user experience. **Current behavior before PR:** --------------------------------- - The invite dialog stays open after creating a group chat **Desired behavior after PR is merged:** ----------------------------------------- - The invite dialog closes after creating the group chat - No extra dialogs remain open **Task:** 5440535 --- I confirm I have signed the CLA and read the PR guidelines at https://www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241881 Forward-Port-Of: odoo/odoo#241504
A minor typo in the l10n_ec_edi_pos module caused the incorrect 'Consumidor Final' partner to be selected during refund processing for Deco Addict orders. This fix corrects the typo, ensuring the correct partner is used, and preventing potential reporting discrepancies.
Original PR description
Step to reproduce: - install l10n_ec_edi_pos - start pos and settle order with specific partner(ex. Deco Addict) - process the refund for this order Observation: - on product screen, "Consumidor Final" is selected instead of Deco addict. Cause and Fix: - Fixed a typo: it used `final_consumer_id` instead of `_final_consumer_id` opw-5412346 Forward-Port-Of: odoo/enterprise#103128 Forward-Port-Of: odoo/enterprise#102202
This update corrects a previous development step where QR and payment details were missing from invoices. The team has added these crucial elements to ensure accurate reporting and compliance with local regulations. This resolves issues OPW-5385872 and OPW-5414922.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
6 changes
Enhancements to existing features
This update adds a helpful link within the Accounting Settings to Odoo's documentation on Deferred Expenses and Revenue management. This provides users with immediate access to detailed information and best practices for handling these complex accounting processes, improving accuracy and understanding.
Original PR description
In the Accounting Settings, add a "?" icon that points at the Odoo documentation on Deferred Expenses and Revenue management. task-5418388 Forward-Port-Of: odoo/enterprise#103090
Resolved issues and error corrections
This update corrects a bug in the forum post form where fields were incorrectly marked as invalid, even after submitting the post. The change ensures that title and description fields are properly validated, improving the user experience and preventing incorrect form behavior. This fix was implemented as part of a larger refactoring of website widgets.
Original PR description
Steps to reproduce =================== 1. Go to Forum. 2. Select any forum and Click on New Post. 3. Add a title and keep description empty. 4. Post Your Question. => The title is marked as invalid. 6. Now add a description. 7. Post Your Question. => Both the title and description are marked as invalid, yet form is submitted successfully. After commit [1], refactoring public widgets to Interactions, the `is-invalid` class toggle for forum post title and description used an incorrect condition, leading to improper highlighting of these fields. [1] https://github.com/odoo/odoo/commit/22e777c046521f3f89b62caa5876680beb7f5aba Task-5400394 Forward-Port-Of: odoo/odoo#241540
This update fixes an issue where the 'Jump to Present' button in non-aside chatter was unreliable, causing flickering and incorrect scrolling. By disabling a browser feature that interfered with scrolling, this change ensures the button reliably jumps to the latest message, improving user experience.
Original PR description
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the…
**Description of the issue this PR addresses:** ------------------------------------------------ In non-aside chatter, the **Jump to Present** action did not work reliably. When users clicked it, the view flickered and the scroll position jumped back, preventing users from reaching the latest message. This happened because the browser’s native scroll anchoring interfered with the scroll-to-bottom behavior when messages were reloaded. **Current behavior before PR:** --------------------------------- - In non-aside chatter, clicking **Jump to Present** caused flickering. - The view jumped back instead of staying on the latest message. - Users could not reliably reach the most recent messages. **Desired behavior after PR is merged:** ----------------------------------------- - Clicking **Jump to Present** in non-aside chatter scrolls directly to the latest message without flickering. - The scroll position remains stable and does not jump back. - The **Jump to Present** button works consistently. **Task:** 5264332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240934
This update corrects a technical issue where invoice reports in the l10n_co_edi module were missing crucial QR codes and payment information. The team has extended the existing view to ensure all invoices accurately reflect these details, improving reporting accuracy and compliance. This resolves issues OPW-5385872 and OPW-5414922.
Original PR description
During the commit 6479d17, a new view was added but unfortunately, the details of the previous one was not considered. To fix this issue, we should extend the values of the main one. OPW-5385872 OPW-5414922 Forward-Port-Of: odoo/enterprise#103039
This update fixes a crash that occurred when switching tabs while a receipt was being printed in Point of Sale. The change ensures the receipt component is correctly loaded and accessible, preventing the printing process from failing. This improves the reliability of automatic receipt printing.
Original PR description
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay…
Steps to reproduce: ------------------- 1. Enable "Automatic Receipt Printing" so the receipt is auto printed after paying an order 2. From PoS, make an order, select it to invoice, and click the pay button. 3. While loading (normally a few seconds to finish the invoice), switch the tab and stay there for few seconds (the time the invoicing has finsihed). 4. Come back to the initial page, a traceback will appear and the ticket is not printed. Why it happens: --------------- The receipt is printed when the parent of the `OrderReceipt`, i.e. `RenderContainer` is rendered. In this case, we assume that `OrderReceipt` has already had the time to be mounted and thus it's in the DOM, so in this case, `this.ref?.el?.firstElementChild` has the order receipt. However, when switching the tab, and since OWL uses `requestAnimationFrame` as a scheduler, and since the browser will throttle `requestAnimationFrame` when the tab is not active, we will not have access to the order receipt component in its parent's `onRendered`! The fix ------- Instead of seeing the parent renders as a sign that its child has been successfully put in the DOM, we now renders the child component (OrderReceipt) in its own container and thus we can hook into its `onMounted` lifecycle where we know for sure that this component has been successfully mounted and attached to the DOM, and can be accessed through `this.ref?.el?.firstElementChild`. opw-5124585 Forward-Port-Of: odoo/odoo#241781 Forward-Port-Of: odoo/odoo#239008
This update fixes a visual issue in the Point of Sale interface where the left-hand product selection pane would sometimes shrink, making text unreadable. The fix ensures the pane maintains its intended width, improving the user experience. The issue was intermittent and related to how the layout elements were interacting.
Original PR description
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and…
In some scenarios, although not fully deterministic, the left pane is being pushed by its right pane sibling (i.e. the products grid), making it go below its specified with of `left-pane-width`, and making text non readable. By setting `flex-shrink: 0` on this element, we tell the browser to respect the specified width, and not allow its siblings to shrink it. We could have also set `min-width: $left-pane-width;`, but it's less descriptive. The problem happens because we are in a flex container, hencer we use `flex-shrink: 0`. ### Notes: This issue only happened from time to time for the client, and it seems non deterministic. If we disable showing the product images, the issue stops happening. The below before vs after screenshots are taken on MacBook Pro 14 inches. ### Before: <img width="1493" height="868" alt="image" src="https://github.com/user-attachments/assets/70bc5a70-34a6-48c9-a60a-ab1de1fa0b9b" /> <img width="1496" height="867" alt="image" src="https://github.com/user-attachments/assets/e8ae9b25-3525-439b-93dd-18dc825613c7" /> ### After: <img width="1495" height="866" alt="Capture d’écran 2025-12-31 à 11 28 38" src="https://github.com/user-attachments/assets/23585d3d-b0bf-4316-8749-b39a56fc8cda" /> <img width="1497" height="866" alt="image" src="https://github.com/user-attachments/assets/f5654163-1dd3-4ff9-bb12-d8cd8fbc497b" /> opw-5392359 Forward-Port-Of: odoo/odoo#241941 Forward-Port-Of: odoo/odoo#241731