Tuesday, February 20, 2024
14 changes · saas-17.1
Resolved issues and error corrections
This update resolves an issue where Odoo was displaying error messages from external pages when the live chat was embedded. The change removes a problematic error service that was incorrectly catching errors, leading to disruptive popups. This improves the user experience for live chat embeds.
Original PR description
Before this commit, an Odoo dialog would open to show errors that occurred in the pages embedding the live chat. We should not display errors originating from outside the embedded script. Moreover, the error service listens to the error event on the window object. Thus, errors occurring in the shadow DOM won't be caught. As a result, the error service disrupts the site that embeds it and is entirely useless for the live chat. This PR removes the error service from the embedded live chat. OPW-3699040 Forward-Port-Of: odoo/odoo#154102 Forward-Port-Of: odoo/odoo#154012
This update resolves a visual issue where tables within task descriptions would sometimes overflow the designated field, particularly when a new row was added above. The fix ensures that table widths are only set on the initial row, allowing for scrollable tables and preventing layout problems. This improves the user experience when creating and viewing task descriptions.
Original PR description
Reproduction: 1. In project -> task, create a new task 2. In the description, make a table of 1 row 2 columns, type two line long string in the second cell 3. Create a row above, type anything short, save 4. Add the portal user as follower, e.g. search user joel 5. In an incognito tab log in with portal portal, check the task and the table is out of the field Fix: Only set the width of the cells when it’s the first row and there’s other preset style of width for existing cells task-3559104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154569 Forward-Port-Of: odoo/odoo#139016
This update resolves a bug where cursor movement near zero-width spaces in the editor caused the cursor to jump to the wrong block. The fix ensures accurate navigation within the editor, preventing users from unintentionally bypassing sections of text. This improves the overall editing experience.
Original PR description
Description of the issue this PR addresses: In cases where the cursor is at the end of the current block and the next block begins with a zero-width space, the mechanism that skips these characters while using arrow keys should not traverse all the way to the end of the zero-width space in the next block. Because this mechanism operates before the browser applies its own behavior for arrow keys, potentially causing the cursor to jump to the start of the third block when second block only contains a zero-width space, completely bypassing the second block. Conversely true for the arrow left keys. This commit ensures that the navigation does not extend beyond the current block when searching for a `newFocusNode` when moving with arrow keys near zero-width space. task-3653307 Forward-Port-Of: odoo/odoo#154676 Forward-Port-Of: odoo/odoo#153217
This update resolves an issue where clicking a document multiple times in the Documents activity view would open multiple 'Schedule Activity' wizards. The fix ensures that the wizard opens only once, streamlining the scheduling process and preventing user frustration with lingering windows.
Original PR description
**Steps to reproduce:** - Go to Documents activity view. - Click on Schedule activity. - Perform multiple clicks on any document. **Issue:** The 'Schedule Activity' wizard opened as many times as the document was clicked. As a result, even after successfully scheduling an activity on that document, the user still faced multiple open wizards remaining and had to manually close each one of them. **Fix:** This PR introduces a method `executeOnceAndClose` which makes use of a flag 'busy' to ensure that the `onSelected` function is called only once and hence exactly one `Schedule Activity` wizard is opened, despite clicking a record more than once. Task: [3721404](https://www.odoo.com/web#id=3721404&menu_id=4722&cids=2&action=333&active_id=10888&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#154442 Forward-Port-Of: odoo/odoo#153869
This update corrects a bug where a purchase bill automatically assigned the salesperson from the original purchase order, even when a different user (the purchase representative) created the bill. This ensures bills are correctly associated with the intended buyer, preventing unnecessary notifications and streamlining the billing process. This change improves data accuracy and user experience.
Original PR description
Steps to reproduce: - Install Accounting and Purchase - Create a PO with Purchase Representative different from current user (e.g. Marc Demo) 1) - Mark the product as received - Create a bill from PO 2) - Go to Accounting - Create a bill - Select the PO in Auto-Complete field - Save the bill Issue: The Purchase Representative of the PO is set as Salesperson (hidden field) of the bill. He should not. The default user (i.e. the current user) should be the Salesperson. In the second case, by adding the purchase representative as Salesperson of the bill, he is also added as a follower of the bill and he receives a notification about being assigned to the bill. opw-3677713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154356 Forward-Port-Of: odoo/odoo#151814
This update resolves a bug where delivery pricelists with discounts were incorrectly applied twice when displayed on sale orders. Due to limitations in the stable version, the visibility of these discounts on sale orders has been removed to ensure accurate pricing. This change prevents overcharging and maintains correct order totals.
Original PR description
If user created pricelist which applied discount on fixed prize delivery and set the discount visibilty to be shown in sale order, the discount would be applied twice. Due to stable version limitation, the visibility of discount on sale order for pricelist discount for delivery is removed. opw-3517879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154470 Forward-Port-Of: odoo/odoo#152816
This update fixes an issue where negative quantities on Sales Orders with 'delivered quantities' invoicing policies weren't correctly reflected in invoices. The change ensures that delivered quantities are updated negatively on the SO, allowing for accurate invoicing, mirroring the behavior in the POS and return scenarios. This prevents discrepancies between the SO and the generated invoice.
Original PR description
Current behavior: - Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks.…
Current behavior: - Creating an SO with negative quantities for a storable product with an invoicing policy of type "delivered quantities" automatically generates a return move for the stocks. However, when this delivery is validated, the delivered quantities are not updated on the SO. This is problematic as these quantities are therefore not taken into account on the associated invoice. Expected behavior: - The delivered quantities should be updated negatively on the SO to enable the invoicing of these lines. This is already the behavior in the POS application and when you create an SO with positive quantities followed by a return for a larger quantity than the one delivered. Steps to reproduce: - Create a storable product with an invoicing policy of type "delivered quantities". Create an SO with 2 lines: - a line with positive quantities for any other product. - a line with negative quantities for the product you created. Confirm and validate the corresponding deliveries. Return to the SO. The quantities for the second line are not updated. Create an invoice. The second line is not taken into account. Cause of the issue: - The to_refund field of the stock.move model defined in the stock_account module enables a decrease of the delivered quantities in the associated Sale Order. This field is set to True for "classic" returns but not for the stock.move generated from sale.order.line with negative quantities. Fix: - We rely on the _get_custom_move_fields method to add the to_refund field in the procurement 'values' arguments in case the stock_account module is not installed. It is then available to use in the _get_stock_move_values method where we set its value to True if the quantity is negative (so that the move should be considered as a refund). opw-3676045 - --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154496 Forward-Port-Of: odoo/odoo#152466
This update resolves an issue where the spreadsheet's share button dropdown menu displayed a scroll bar in certain languages. The fix adjusts the dropdown's height to automatically fit the content, ensuring a clean and consistent user experience across all languages. This improves usability for all users.
Original PR description
## Description: Previously, an issue was observed where the dropdown menu of the spreadsheet's share button displayed a scroll bar when users had selected a different language, such as French (BE). This PR addresses the problem by setting the height of the dropdown menu to auto, thereby resolving the issue of unnecessary scroll bar. Task ID: [3742260](https://www.odoo.com/web#id=3742260&cids=2&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#154561 Forward-Port-Of: odoo/odoo#153834
This update resolves an issue where clearing an autocomplete field wouldn't trigger a record save. The fix ensures that changes to the autocomplete value are correctly detected and saved, preventing data inconsistencies. This improves data integrity and reliability.
Original PR description
This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce: - go to an empty autocomplete and click on it…
This commit fixes a pretty specific issue within autocomplete behavior where the change event after clearing the value is prevented. Steps to reproduce: - go to an empty autocomplete and click on it - start typing a search with results - click on the first result - without focusing out, clear the input and finally click out No change event is triggered on click out in this case so the cleared value is not updated in the end and saving the record will keep the non cleared value. The t-on-mousedown.prevent in the dropdown was mainly used to keep the focus on the input after selecting a value for the autocomplete. This introduces a side effect: when one starts typing on the initially empty autocomplete, the browser keeps the initial value of the input in memory until it is focused out (and therefore blurred). When the input is focused out, it will compare the current value of the input with the stored initial value and decide to trigger a change event based on the comparison between the two values: if these are different, the change will trigger. In our case, since the mousedown event on a search result is prevented, no focus out will happen and therefore the browser will still wait for the next focus out to trigger the eventual change event. But since we clear the input before focusing out, the two values are empty and no change event is triggered which introduces the issue. To fix it, we remove the t-on-mousedown.prevent of the template and manually avoid triggering the onInputBlur method with a flag to keep the previous behavior and we finally focus on the input programatically after selecting a value. task-3734818 Forward-Port-Of: odoo/odoo#154448 Forward-Port-Of: odoo/odoo#154203
This update corrects a bug where inactive tax settings incorrectly continued to influence fiscal position mappings. Now, when a tax is marked as inactive, it no longer affects related fiscal positions, ensuring accurate reporting and compliance. This improves data integrity within the accounting system.
Original PR description
When a tax is set to inactive, the fiscal positions mapping other taxes to it continued to apply, disregarding the fact that it shouldn't be used anymore. Not anymore with this fix. task-3751224 Forward-Port-Of: odoo/odoo#154464 Forward-Port-Of: odoo/odoo#154246
This update resolves an issue where the website editor's mobile order feature was limited to a maximum of 12 columns. The team decided to switch to inline styling to remove this restriction and ensure a more flexible layout for users. This change improves the usability of the website editor.
Original PR description
Commit [1] introduced mobile orders for columns in flex containers snippets. This was later amended with commit [2] to use Bootstrap's `order-X` classes. Finally, to be complete, commit [3] also added some manipulations around mobile orders. Those classes are limited to 12 possible orders, which means the feature stops working for any column over that threshold: a column with `order-13` will appear as if it didn't have any order. In the end, it has been decided that the trade-off of being capped at 12 mobile orders (and so 12 columns) and the behavior it causes isn't worth using the classes: we will use inline style instead. [1]: https://github.com/odoo/odoo/commit/710d000f1872fd99b41d52ec3d6923756bba7cba [2]: https://github.com/odoo/odoo/commit/143bdfa13d331b93b88e207f181840d91796cdce [3]: https://github.com/odoo/odoo/commit/7b27385dba36c2e741d96e76ad5d847d09f2b084 task-3666688 Forward-Port-Of: odoo/odoo#152024
This update fixes an issue where the homeworking feature on mobile devices wasn't functioning correctly due to a conflict with another element on the screen. We've replaced the popover with a dialog, ensuring that users can now easily access and utilize the homeworking functionality on their smartphones and tablets. This enhancement improves the overall user experience.
Original PR description
On mobile, the homeworking popover was conflicting with the `#scheduling_box`. The latter was covering the buttons of the popover. To solve this, we replace the popover by a dialog on mobile. task-3630139 part of task-3575827 | Before | After | |--------|--------| |  | <img width="381" alt="Capture d’écran 2024-02-19 à 10 42 06" src="https://github.com/odoo/odoo/assets/80679690/c4c1bebb-3137-41d2-a69a-76083a549ddd"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145446
This update resolves an issue where orders created through the POS kiosk were incorrectly duplicated on the cashier's side. The fix ensures that orders are accurately reflected, preventing confusion and improving the reliability of order management within the kiosk system. This change was made to enhance the user experience and data accuracy.
Original PR description
Issue: - when an order is created through the kiosk, the order appears several times on the cashiers side. Steps to Reproduce: - Make an order in the POS kiosk. - In the backend, navigate to the kiosk's session and select "Continue Selling." - Click on "Orders" located on the top right. - Observe that the order appears multiple times on the cashier's side. Solution: - added _get_shared_orders that retrieve orders without duplicates. opw-3597973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#149049
This update corrects a bug in the invoice reporting process that was causing errors when generating invoices with multiple payment due dates. The fix ensures that early payment discount eligibility is correctly calculated, preventing a traceback and ensuring accurate invoice amounts. This resolves an issue where the system incorrectly bypassed discount eligibility rules.
Original PR description
### Steps to reproduce issue: 1. Create Draft invoice with no Invoice Date 2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days) 3. Make sure "Show installment dates" is…
### Steps to reproduce issue:
1. Create Draft invoice with no Invoice Date
2. Set payment terms with multiple due dates (e.g.: "30% Now, Balance 60 Days)
3. Make sure "Show installment dates" is ticked in the payment terms form
4. Print invoice
5. Receive traceback with main message:
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> ValueError: The value send to monetary field is not a number.
> Template: account.report_invoice_document
> Path: /t/t/div[2]/div/div[3]/div[2]/t/div/div/t[1]/td/span[1]
> Node: <span t-options="{"widget": "monetary", "display_currency": o.currency_id}" t-out="o.invoice_payment_term_id._get_amount_due_after_discount(o.amount_total, o.amount_tax)"/>
### Explanation:
`_is_eligible_for_early_payment_discount` will normally return `True` only if every condition is fulfilled. In previous fix odoo@9b20af823d3d2d8c3c70fd016d71448caa039958, we bypassed all of them if `reference_date` had no value.
https://github.com/odoo/odoo/blob/4b744c82c3f902448a5c89c4711eccfeb1b548b8/addons/account/models/account_move.py#L1910-L1918
The method is called here, leading to the field that triggers the traceback.
https://github.com/odoo/odoo/blob/8f3c0b218eb9ea725995d716e97999556ce74578/addons/account/views/report_invoice.xml#L230-L236
The reason it only blocks with multiple due dates is because of the first line: `payment_term_details` is true when there are multiple due dates or an early discount, the latter being the concern of the previous fix.
The second one is true if "Show installment dates" is ticked.
### Suggested fix:
`reference_date` should not take priority. Therefore, we will only override its own condition when it has no value.
opw-3726968
Forward-Port-Of: odoo/odoo#153401