Daily updates from Odoo
Tuesday, February 20, 2024
47 changes
14 changes
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#1534011 change
Resolved issues and error corrections
This fixes tax calculation errors in complex real-world cases involving included taxes, fixed fees, and division-based taxes used in countries such as India, Belgium, and Brazil. Businesses should see more reliable invoice totals, tax amounts, and fiscal position mappings, reducing discrepancies in accounting and compliance workflows.
Original PR description
REAL TAX CASES TO COVER INDIAN CASE: 6% incl + 6% incl + 3% excl Both 6% incl must always have the same tax amounts (not working in master but fixed as well in this task). The 3% must be based on 12%…
REAL TAX CASES TO COVER INDIAN CASE: 6% incl + 6% incl + 3% excl Both 6% incl must always have the same tax amounts (not working in master but fixed as well in this task). The 3% must be based on 12% (working thanks to the is_base_affected checkbox). BELGIUM CASE: fixed tax + 21% incl (recupel case) That's for this case we allow to mix price-excluded with price-included taxes. BRAZILIAN CASE: 5 taxes having the 'division' type: 5% 3%, 0.65%, 9% and 15%. This case is tricky because it's based on the price-included amount and the whole computation was made only from the price-excluded amount. With a base of 48.0, the base amount of the 15% tax is computed as 48.0 * (1 - 0.15) = 40.8 so a tax amount of 48.0 - 40.8 = 7.2. So the respective <base, tax_amount> of each taxes are: 45.6, 2.4 46.56, 1.44 47.69, 0.31 43.68, 4.32 40.8, 7.2 ...and the price-excluded amount is 40.8. PROBLEMS TO SOLVE INDIAN CASE: Suppose a base of 100 with 2 x 6% incl taxes. The behavior in master: a - Find the price-excluded base: 100 / 1.12 ~= 89.29 b - Compute the first 6% incl tax amount: 89.29 * 0.06 = 5.36 c - Compute the second 6% incl tax amount. Since it's the last one before the "cached base amount of 100", it's computed as 100 - 89.29 - 5.36 = 5.35 => 5.35 != 5.36 The behavior in the current task: a - Compute the base amount for the computation of the 2 x 6% incl taxes: 100 / 1.12 = 89.2857 b - Compute the tax amount for the 2 taxes: 89.2857 * 0.06 = 5.357142 ~= 5.36 c - Compute the base amount of the 2 x 6% incl taxes: 100 - 5.36 - 5.36 = 89.28. => Problem solved BELGIUM CASE: Suppose a base of 120.90 with 0.10 fixed tax (must be include_base_amount), then 21% incl tax. The behavior in master: a - Find the price-excluded base: 120.90 / 1.21 = 99.92 b - Compute the percentage tax: (99.92 + 0.10) * 0.21 = 21.0 => total tax is 21.0 + 0.10 = 21.10 but the base is 99.92 so the total of the invoice will be 121.02. The results is supposed to be the same as 2 lines: line1: 120.90 with 21% incl tax line2: 0.10 with 21% incl tax ...giving a price total of 121, a price subtotal of 100 and a tax amount of 21. The behavior in the current task: a - First ascending computation: Compute first the tax amounts of the fixed taxes: 0.10. b - Descending computation: Compute the base and tax amounts for the 21% tax: (120.90 + 0.10) / 1.21 = 100 then 100 * 0.21 = 21.0. c - Second ascending computation: Compute the base of 0.10 being 120.90. BRAZILIAN CASE: As said before, from 40.8, it's impossible to recompute the correct tax amounts. Suppose a base of 48.0 with 5% 3%, 0.65%, 9% and 15%, all division price included taxes. The behavior in master: a - Find the price-excluded base: 48.0 * (1 - 0.3265) ~= 32.33 b - Wrongly compute the tax amounts price-excluded for 5%, 3%, 0.65%, 9%: tax of 5%: 32.33 / 0.95 - 32.33 = 1.7 tax of 3%: 32.33 / 0.97 - 32.33 = 1.0 tax of 0.65%: 32.33 / 0.9935 - 32.33 = 0.21 tax of 9%: 32.33 / 0.91 - 32.33 = 3.2 c - the tax of 15% takes the remaining amount: 48.0 - 32.33 - 1.7 - 1.0 - 0.21 - 3.2 = 9.56 => Nothing works at all... The behavior in the current task: a - Descending computation: Compute the base and tax amounts for all taxes: 48.0 * 0.95 = 45.6; 48.0 - 45.6 = 2.4 48.0 * 0.97 = 46.56; 48.0 - 46.56 = 1.44 48.0 * 0.65 = 47.69; 48.0 - 47.69 = 0.31 48.0 * 0.91 = 43.68; 48.0 - 43.68 = 4.32 48.0 * 0.85 = 40.8; 48.0 - 40.8 = 7.2 REMAINING PROBLEMS Even the taxes computation will be fixed by this commit, some issues remain: -rounding issues on POS global discount/loyalties -bad computation of combo product with complex taxes -python taxes not working on the POS -perf of the tax details queries -round globally not working due to the accounting grouping key -... For all those reasons, this commit also adds new cool features: The taxes computation is splitted in 2 parts: a - prepare_taxes_computation that gives a formula to compute each tax independently. b - evaluate the taxes computation given by (a). This will help a lot to change the tax details query later by: a - pre-compile the taxes combinations first python-side. b - compute the tax details in SQL. The taxes computation is now completely reversible if you don't have any rounding in the process and thus, would help to solve the global discount/loyalties/product combo taxes computation. Also, the fiscal position mapping is now more accurate and is able to manage division taxes as well. The method are splitted in a way is will be quite easy to fix the round globally: Instead of: For each line, create a tax detail per repartition line Sum the tax details per repartition line and create tax lines => It gives a sum of rounded amounts that could be far from the expected amount: round(base * percentage). Do: For each line, create a tax detail per tax. Sum the tax details per tax and round them if round_per_line. Spread the amounts onto the repartition lines. => It will give exactly the tax amount expected by the user: round(base * percentage). opw: 3443703
32 changes
Resolved issues and error corrections
Users can now edit their mobile calling preferences directly from their user settings view. Previously, this setting was read-only and could only be changed elsewhere. This fix ensures the mobile call option field works properly with default values and maintains data consistency.
Original PR description
Same as on user.preference, `how_to_call_on_mobile` should be editable. Forward-Port-Of: odoo/enterprise#52240
This fix ensures that when customers pay for subscriptions, only payment methods that support secure tokenization (saving payment information) are available. This improves security by preventing unsupported payment methods from being used for recurring subscription charges, reducing payment failures and fraud risks.
Original PR description
This commit adds an override of the `payment.method::_get_compatible_payment_methods` method to force payment methods to support tokenization when paying for a subscription. task-3640488 See also: - https://github.com/odoo/odoo/pull/150120
Fixed an issue where automatically generated renewal invoices for subscriptions were not being sent to customers. When a subscription renews and a new invoice is created, it will now be properly delivered to the customer instead of remaining unsent in the system.
Original PR description
To reproduce ============ - Create a subscription with a monthly period - Send it to client and pay it on portal (by strip for example) - Wait for the next renewal date (change date to future) - execute manually the crons : - Sale Subscription: generate recurring invoices and payments - payment: post-process transactions - The invoice is created but not sent to the customer or posted in chatter Problem ======= the condition `not invoice.is_move_sent` is true in this use-case which will block sending the invoice, in this context this condition does not make sense as we want to send the unsent invoice so it's removed in this commit opw-3691557
This update fixes reliability issues in the Shop Floor manufacturing test suite by adding extra verification steps to prevent timing errors. The changes also streamline how the system handles adding components and by-products to manufacturing orders, ensuring the process works correctly with the updated Shop Floor interface where manufacturing orders are now the primary focus.
Original PR description
Adds a bunch of extra steps in the tour to avoid race errors. Also, make some minor changes in the code: - `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to…
Adds a bunch of extra steps in the tour to avoid race errors. Also, make some minor changes in the code: - `action_add_byproduct` and `action_add_component` for `mrp.production` call `ensure_one` to be sure those methods are called with an existing record, and the ones from `mrp.workorder` call the `mrp.production` method to avoid duplicate; - For the `mrp_workorder.additional.product` wizard, the `production_id` is now got from the context. Before, it was `workorder_id` who was took from the context, but it does not make sense since the tablet view was dropped for the Shop Floor (where the MO is now the main model). Also, the `company_id` is now related from the MO. - Regarding the previous point, we pass the key `'production_id'` instead of `'default_production_id'` in the context to avoid the propagation to the creation of the move (otherwise, a component move will have the `production_id` field set and the move will also be count as a by-product move.) Run build error: 56688
This fix resolves an issue where approval rules created for one model were incorrectly interfering with rules for other models that had methods with the same name. The problem occurred because the system wasn't properly filtering rules by their associated model. After this fix, approval rules now work independently for each model without conflicts.
Original PR description
…me method Have two models that have a method with the same name. Create multiple rules for model 1 and 1 one rule for model 2 Before this commit, the rule on model 2 will interfere with model 1. This was because some domains missed to filter on the model of the rule After this commit, rules are not colliding between models. opw-3734028
This fix corrects how the system calculates whether a bill is ready to be paid. Previously, when section or note lines were added to a bill, the payment status would incorrectly show "Exceptions" instead of "Yes". The fix ensures these non-product lines are properly excluded from the payment readiness calculation, so bills display the correct payment status.
Original PR description
Steps: - Create a PO, confirm and receive the product - Create the bill from the PO - On the bill form add a section/note - Go to Other Infos tab -> "Should be paid" is set to "Exceptions", it should be "Yes" This is because we don't exclude section and note from the line when computing the field `release_to_pay` opw-3724937 Forward-Port-Of: odoo/enterprise#56622
This update corrects how dates are filtered in the ATS (Anexo de Transacciones Sustentorias) tax reports for Ecuador. The system now properly uses the accounting date field instead of other date references, ensuring compliance with SRI (tax authority) documentation requirements. This fix ensures accurate tax reporting for Ecuadorian businesses.
Original PR description
According the SRI documentation, we should consider the accounting date (field date) on the search filters Forward-Port-Of: odoo/enterprise#55547
Accountants can now see online banking accounts and links with the same visibility rules as regular journal accounts across multiple company branches. Previously, accountants could view parent company journals but were unable to see the corresponding online accounts and links, creating an inconsistency in data access that has now been resolved.
Original PR description
Accountants were able to see account.journal of parent companies, but not online accounts and links. This commit sets the same visibility for the 3 objects ticket-3748174
Fixed an issue where the Digital Signature module was incorrectly displaying a "send" button on shared unsigned documents. Since shared documents don't have an associated email address, clicking this button would cause an error. The button is now hidden for shared document requests, improving the user experience.
Original PR description
After the sign conversion to OWL, when accessing an unsigned shared document it would show a "send" button close to the public user. However, since it's a shared document, there is no email to send the document to. Clicking on it, will cause a traceback. This commit hides this button for shared requests. task-3710635 Forward-Port-Of: odoo/enterprise#55470
This fix resolves an issue where sales orders with custom sequence prefixes (like year-based formats) couldn't be matched during bank reconciliation. The system now correctly identifies and matches sales orders regardless of the sequence prefix format used, making the bank matching process more reliable.
Original PR description
Steps to reproduce: - In Sequences > Sale order: change the prefix with `%(year)s` - create a SO; mark quotation as sent - create a bank statement with the same label as the SO's name - try to match Issue: No "sale orders" tab will ne displayed Cause: ``` > [x.lower() for x in text_tokens if x.lower().startswith(sequence_prefix)] [] ``` Since `sequence_prefix` would be `%(year)s` and the the label `202400022` Solution: Simplify everything with an orm search opw-3663266 Forward-Port-Of: odoo/enterprise#56904 Forward-Port-Of: odoo/enterprise#55450
This fix prevents duplicate bank transactions from being created when the bank data provider occasionally returns duplicate entries in a single sync. The system now automatically detects and ignores duplicate transactions with the same identifier within the same sync operation, ensuring accurate bank statement records.
Original PR description
…ies in some case In a few rare cases, an issue with the provider can cause the transactions to be duplicated within the same call to fetch transactions. This commit fixes the issue by ignoring entries within the same call that would happen to have the same transaction_identifier. Forward-Port-Of: odoo/enterprise#56579 Forward-Port-Of: odoo/enterprise#56165
This fix resolves an issue where task information buttons were not updating correctly when a duplicated sale order was assigned to a field service task. Previously, the system would retain links to the old sale order instead of updating to the new one. This ensures that users see accurate and current sale order information in their tasks.
Original PR description
### Steps to reproduce: - Create a sale order with a service - Create a task in field service. - Link the sale order with the task - Duplicate the sale order. - Assign the new sale order to the task. - The smart buttons in this case aren't being updated and they remain linked to the previous sale. You can see this in the following video. ### Investigation: - The smart button is related to the `sale_order_id` - the method `_compute_sale_order_id` tends to set the sale_order_id to the old value saved in `fsm_task_to_sale_order` before calling the parent `_compute_sale_order_id` even if the new value is not False -which is the purpose of the override- https://github.com/odoo/enterprise/blob/d9e66635dd3c2e9b994280b5e81fd53decbbf9d2/industry_fsm_sale/models/project_task.py#L168-L169 opw-3700469 Forward-Port-Of: odoo/enterprise#56115
This update corrects an issue in the helpdesk timesheet tests where test cases were inadvertently using demo data instead of data created specifically for testing. The fix ensures that tests create and use their own helpdesk team data, making tests more reliable and independent from demo data.
Original PR description
Before this commit, the ticket is set to a random helpdesk team with the id equals to 2 which is surely the id of a demo data (VIP Support). This commit makes sure the ticket created inside the test will be linked to a helpdesk team created in the test and not a helpdesk team linked to the demo data. runbot-57412 Forward-Port-Of: odoo/enterprise#56944
This update fixes an unreliable test in the timesheet holidays feature that could fail when demo data contained public holidays on the current date. The fix ensures the test runs consistently by using a fixed test date instead of relying on the current date, making the system more stable and reliable.
Original PR description
Before this commit, when the demo data adds a public leave for the current day, the test `test_adjust_grid_holidays` could fail because we could fetch the timesheet generating the public leave instead of the one created. This commit adds a freeze_time on the test to be sure the current date is not the current one but `2018-06-02`. runbot-57194 Forward-Port-Of: odoo/enterprise#56884 Forward-Port-Of: odoo/enterprise#56524
A recent feature allowed users to resend multiple documents at once, but it incorrectly attempted to resend shared signature requests, which cannot be resent to public users. This fix filters out shared requests from bulk resend operations, allowing users to select all documents while only resending those that can actually be resent.
Original PR description
https://github.com/odoo/enterprise/pull/40112 allowed resending documents in mass, however it does not check for shared sign requests. Since shared sign requests are targetted at public users, it is not possible to resend them. This PR fixes this by ignoring the shared sign requests. It was chosen to ignore them because we still want to allow selecting all documents and resending only the ones that can be resent. task-3721338 Forward-Port-Of: odoo/enterprise#55824
Fixed an issue where clicking on a related purchase in the Asset form would display a confusing technical view. Now users see a clickable purchase document name instead, making it easier to navigate to the actual purchase they want to review.
Original PR description
- Create an asset - Add a related purchase in tab Bills. - Click on the related purchase. => You have the horrible form view of an aml, which is something we want to avoid at all costs. We instead prevent the opening and add a clickable name of the move, as it is what people would want to see. task-3749634 Forward-Port-Of: odoo/enterprise#56899
This fix resolves an issue where orders created through the POS kiosk were appearing multiple times when cashiers viewed the orders list. The solution prevents duplicate orders from being displayed, ensuring a cleaner and more accurate order management experience for staff.
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
This update fixes two important payment processing issues. First, it ensures that payment method compatibility checks now properly consider all relevant parameters, allowing customizations to work correctly. Second, it improves consistency by automatically archiving stored payment tokens when a payment method is disabled or loses tokenization support, preventing customers from attempting payments with blocked methods.
Original PR description
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method,…
[FIX] payment, sale: forward kwargs to `_get_compatible_payment_methods` The keyword arguments of the callees were never forwarded to the `payment.method::_get_compatible_payment_methods` method, preventing overriding modules from controlling which payment method should be available depending on the kwargs. task-3640488 --- [FIX] payment: archive tokens of payment methods blocking tokenization When a payment method was updated in a way that prevented creating tokens with it, that is, by either disabling it, unchecking the "Tokenization Supported" field, or unlinking it from providers, only the latter would automatically archive the related tokens after showing a warning to the user. The two first actions prevented the creation of future tokens with that payment method, but existing tokens could still be used. This commit fixes that behavior by adding the warning and the automatic archiving of related tokens where they were missing. Preventing further tokenization with a payment method now consistently blocks payments through existing tokens, too. --- See also: - https://github.com/odoo/enterprise/pull/54700
Fixed an issue where clicking the Google and Outlook calendar sync pause buttons were incorrectly redirecting users to general settings instead of calendar settings. This update ensures users are now taken to the correct calendar settings page when managing their sync preferences.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. Configure Google and Outlook Calendar and navigate to the calendar app. 2. Click on the Google and Outlook sync button, redirecting to the general settings. **Issue:** Users are now redirected to the general settings by using the Google and Outlook sync button. **Solution:** Update the `doAction` so, users will be redirected to the calendar settings. task-3731652 <hr/> I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a bug in the web editor that prevented users from properly editing link text. When users tried to edit a link's label using the edit icon, the backspace key wouldn't work due to invisible formatting characters. The fix ensures that link editing works smoothly in all scenarios, improving the user experience when managing links in documents.
Original PR description
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the…
This commit resolves a bug related to zero-width spaces within the inner content of a link. The bug led to a systematic test failure in 17.0 link_tools when comparing the input value with the expected value. The bug originated from [1] that manipulates zero-width spaces to allow users to select the edges of the link. Steps to reproduce: - Navigate to the Project app and open a random task (create one if none exists). - Select the "Description" tab. - Enter "/link" and press "Enter" to activate the link tools dialog box. - In the link label field, input "The Website". - In the URL or email field, input "localhost:8069". - Save the changes. - A new div is generated with the class "note-editable". - Click on the newly created link. - Edit the link by clicking on the edit icon in the popover. - Direct the focus to the link label field at the end of the string "The Website". - Press the "Backspace" key — observe that nothing happens. It's maybe just a complement to this [PR] The test added in [2] eliminates zero-width-spaces prior to asserting the equality of values. This was appropriately addresses and handled in this commit. [PR]: https://github.com/odoo/odoo/pull/142135 [1]: https://github.com/odoo/odoo/commit/ab40f48 [2]: https://github.com/odoo/odoo/commit/a56586119845969e9d867a220f5330a6c7daa5c2 runbot-44779 Forward-Port-Of: odoo/odoo#153911 Forward-Port-Of: odoo/odoo#144321
Users in the Documents app experienced a frustrating issue where clicking on a record multiple times while scheduling an activity would open multiple wizard windows. This fix prevents duplicate wizards from opening by ensuring the selection action only executes once, even with repeated clicks, eliminating the need for users to manually close extra 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#154363 Forward-Port-Of: odoo/odoo#153869
This fix resolves a crash that occurred when printing draft invoices with multiple payment installments and no invoice date. The system was incorrectly bypassing validation checks for early payment discounts, causing invalid data to be displayed. The fix ensures proper validation is applied regardless of whether an invoice date is set.
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#153401This fix resolves a crash that occurred when users tried to add new records to a list field (one2many) in forms where the underlying model uses inheritance. The issue happened because the system tried to update a parent record that was empty, causing the operation to fail. The fix ensures the system only updates parent records when they contain valid data.
Original PR description
Consider models A and B such that B inherits from A (with `_inherits`), and a form view of A with a one2many field that inverses the many2one "delegate" field from B to A. When adding a new record in the one2many, `onchange()` crashes while trying to update the cache of an empty parent record. The situation is caused by how `onchange()` initializes the new record of model B, and the fact that the form provides a value for the delegate field. The new record is actually initialized with an empty value for the delegate field, which causes the code to crash. The fix simply consists in updating the parent record only if is nonempty. opw-3744514
The Cancel button in the activity scheduling dialog was using the same keyboard shortcut (z) as another button, causing conflicts. This fix changes the Cancel button's hotkey to x to resolve the conflict and improve user experience when scheduling activities.
Original PR description
Since 17.0, the `Cancel` button in the `mail_activity_schedule_view_form` uses the hotkey `z`, which conflicts with the other button. Change the hotkey into `x`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where rejection emails sent to applicants in batch were being automatically deleted, making HR staff think the emails weren't sent. The system now keeps these emails in the log so HR can verify that communications were successfully delivered.
Original PR description
When HR refuses applicants in batch and sends mails, the mails are removed, because auto_delete_keep_log is set to false. It gives to HR wrong understanding that mails have not been send. Expected behavior; Don't remove refused mails, when sent in batch
This fix resolves a problem where tables in task descriptions would overflow and become misaligned when portal users viewed them. The issue occurred when adding new rows to tables with longer text content. The fix ensures that table columns maintain proper width only when necessary, allowing longer tables to scroll properly instead of breaking the layout.
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 addresses persistent test failures in the website link tools feature that have been causing instability in automated testing. The team has temporarily disabled problematic test steps to restore test reliability while a permanent solution is being developed. This allows the automated testing system to run successfully again.
Original PR description
runbot-57204 Forward-Port-Of: odoo/odoo#154491 Forward-Port-Of: odoo/odoo#154244
This fix resolves an issue in the web editor where using arrow keys to navigate text could cause the cursor to skip over entire blocks of content when those blocks contain special invisible characters. The fix ensures the cursor stays within the current block when navigating, preventing unexpected jumps that could confuse users editing content.
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#154567 Forward-Port-Of: odoo/odoo#153217
This fix prevents the purchase representative from being incorrectly assigned as the salesperson on bills created from purchase orders. Previously, when a bill was created from a PO with a different purchase representative, that person would be added as the salesperson and receive unwanted notifications. Now the current user is correctly set as the salesperson instead.
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
The Cancel button was missing from the activity plan selection dialog in Odoo 17, forcing users to close the dialog using only the X button. This fix restores the Cancel button to provide users with a standard, intuitive way to exit the activity wizard without completing an action.
Original PR description
Restore the "Cancel" button when selecting a plan from the activity wizard. When we introduced the plan feature in v17, the "Cancel" button was forgotten. The only way for users to cancel the action is to click on the "X" button at the top right. task-3754897 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where delivery discounts were being applied twice when users configured a pricelist with discounts on fixed-price delivery and enabled discount visibility in sales orders. To ensure stability, the discount visibility option for delivery pricelist discounts in sales orders has been removed.
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 fix ensures that when a tax is marked as inactive, it will no longer be automatically applied to transactions through fiscal position mappings. Previously, fiscal positions would continue to map to inactive taxes, causing them to be used inappropriately. This change ensures compliance with the intended status of taxes in your 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