Tuesday, February 20, 2024
30 changes · 17.0
Enhancements to existing features
This update improves the performance of spreadsheet currency loading by using a more efficient data retrieval method. The change reduces the amount of data processed when displaying currency information in spreadsheet lists, resulting in faster load times and better overall application responsiveness.
Original PR description
See community commit Task: 3730232
Amazon's SP-API no longer requires AWS credentials or special security signatures as of October 2023. This update removes the unnecessary AWS authentication code from the Amazon sales integration, simplifying the connection process and ensuring compatibility with Amazon's current requirements.
Original PR description
Starting October 2, 2023, SP-API no longer requires the use of AWS Identity and Access Management (IAM) or AWS Signature Version 4, which means ce don't need to sign SP-API requests with AWS Signature Version 4. At first, this change was just a deprecation. But the SPAPI will now ensure this signature isn't present anymore. task-3534880 Forward-Port-Of: odoo/enterprise#56823 Forward-Port-Of: odoo/enterprise#53839
This update improves how spreadsheets load currency information for monetary fields. Instead of making two separate requests to fetch data and then currency details, the system now retrieves everything in a single request. This reduces network traffic and speeds up spreadsheet loading, though with a small increase in data size per request.
Original PR description
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request,…
With this commit, list data is loaded using `web_search_read` instead of `search_read`. The goal is to fetch the currency (symbol, decimal places, etc.) of monetary fields in a single request, instead of 2 RPCs. Pros: - less code - one evaluation saved - one network request saved - easier future refactoring (see below) Cons: - overhead of data transferred over network (from 4.5MB to 6.5MB, unzipped, to fetch a list of 20K crm leads). Before this commit, here is what it looked like: 1. the list data is fetch (with the currency_field) 2. the cells are evaluated with the new data 3. we realize we want to format a currency amount. We already have the currency name but not the symbol, etc. So we fetch the currency data 4. evaluate the cells again with the new currency format Now: 1. fetch the list data with everything we need for the currency 2. evaluate the cells This commit also serves another goal for a future refactoring: in the hope of avoiding throwing "loading errors", I'd like to have an easy way to know if a data source is fully loaded or not (the data and the format). With this commit, everything is centralized in the list data source with a single RPC. The goal is therefore achieved with this commit. Task: 3730232 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The survey results page has been redesigned to improve usability and visual clarity. Changes include optimizing page layout to reduce blank space, repositioning filter buttons, improving table readability with horizontal scrolling, and streamlining the display by removing redundant titles and descriptions. These improvements make survey results easier to read and print.
Original PR description
Add a bunch of QOL improvements in the results page design: - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons…
Add a bunch of QOL improvements in the results page design: - Display the survey results page in half page size to prevent having too much blank space between the tables columns - The filter buttons are now displayed under the survey title - Show the leaderboard bar on the print preview - Changing the eye dropdown icon to a caret for fold/unfold - Align questions to the left to be on the same level as the sections - Add an horizontal scroll to the matrix and simple/multiple choices tables when the screen is not wide enough to display all the data - Reduce vertical spacing between elements to gain space - Reduce simple/multiple choices tables line height - Reduce survey title, section title and KPIs font size - Display the "Correct", "Partial", "Responded" and "Skipped" badges on a single line and set a rounded border around. - Removing the "Result Overview" title - Removing survey description, section description and question description Task-3707687 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
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
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
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
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
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