Monday, February 26, 2024
21 changes · 17.0
Resolved issues and error corrections
Fixed an issue where payment method selections made during payment registration were being overridden by the default payment method stored on the customer record. Now when you explicitly select a payment method in the payment wizard, that selection is correctly applied to the payment instead of reverting to the customer's default setting.
Original PR description
### Summary Currently, when creating a payment, the "payment way" defined on the customer takes precedence over the payments specified on the payment wizard. ### Steps to reproduce * install `l10n_mx_edi` * switch to a Mexican company * create a contact C * on the contact form, in the "Sales & Purchase" tab, set the "Usage" and "Payment Way" to "General expenses" and "Tarjeta de Crédito" respectively. * create an invoice for contact C, with a due date for next month * register a payment, with "Payment way" set to "Efectivo" The payment that is created will have it's "Payment way" set to "Tarjeta de Crédito" (the one defined on the customer), even though you specifically selected "Efectivo" in the payment wizard. opw-3717693
This fix ensures that when users embed a view with active filters (like "My Pipeline") into Knowledge documents, those filters remain active in the embedded view. Previously, default filters were being incorrectly disabled during the embedding process, causing users to see unfiltered data instead of the intended filtered view.
Original PR description
The default filter on a view was not enabled when inserting said view in Knowledge. How to reproduce: - Open a view with a default filter (i.e. `CRM > My Pipeline`) - Insert it in Knowledge Current Behavior: - The default filter is not enabled in the embedded view in Knowledge. Expected Behavior: - Every active filter should be active in the embedded view after being inserted, no matter if it was a default filter or not. Technical explanation: `_activateDefaultSearchItems` is actually a toggler, and in the specific case where a view does not have a default favorite in knowledge, and was inserted with a default filter enabled, the method would toggle it and disable it. task-3742241 Forward-Port-Of: odoo/enterprise#56410
This fix ensures that when a shift spans multiple calendar days but appears as a single block in the Gantt view, the start and end times are now properly displayed on the shift. Previously, the system would hide these times because it thought the shift spanned two days, even though it only appeared once visually. This improves clarity for users viewing shift schedules.
Original PR description
Before this commit, when the shift has the following planned dates: - start date: 2024-02-02 16:00:00 - end date: 2024-03-02 01:00:00 The shift is displayed in one day in the gantt view, the reason is because the gantt view truncates the date if between the date of the end date and the end date there is less than 3 hours than the pill will not be displayed in that day (same logic for the date of the start date and the start date) and will only be displayed in the other days, in that example, the shift will only be displayed in `2024-02-02`. The problem is the custom code in planning considers the shift in 2 days and so the start and end time are not displayed in the pill (=shift in that case) which is a bit annoying. This commit manages that special behavior to ensure the start and end time are displayed in that case since the shift is only displayed in 1 day. opw-3588166 closes odoo/odoo#120206 Forward-Port-Of: odoo/enterprise#57051 Forward-Port-Of: odoo/enterprise#56546
This fix resolves a memory error that occurred when installing the Argentine EDI module on databases with large numbers of accounting records. The solution optimizes how a specific field is initialized during installation, preventing the system from running out of memory during the process.
Original PR description
Issue --> For a database with a large number of `account.move` records, the computation of the field `l10n_ar_fce_transmission_type` leads to a MemoryError when installing the `l10n_ar_edi` module. Solution --> Use the `_auto_init` method to add the column to the `account_move` table to skip computation during installation. Set the value to NULL on init because the field does not have a default value. opw-3694393 Forward-Port-Of: odoo/enterprise#56879
Invoices received through email aliases were being automatically sent for OCR processing even when this feature was disabled. This fix corrects the issue by consolidating the logic that determines when automatic extraction should occur, preventing unwanted automatic processing of invoices.
Original PR description
Since commit d79ac56, invoices coming from the email alias were automatically sent to the OCR even when the automatic sending mode was disabled. The logic that decides whether or not the document should be automatically sent to the OCR was duplicated at multiple places, making this kind of error easy to make. This commit addresses the issue by introducing a new `_check_auto_extract_conditions` function that regroups all the necessary conditions that needs to be met for auto extraction. Ticket #3708420
Fixed a problem where table cells in Studio reports would automatically expand when users typed content. The fix removes an auto-sizing CSS property that was causing tables to change layout unexpectedly. This ensures tables maintain their intended dimensions while editing reports.
Original PR description
Issue: ====== The table row width gets auto increased when you type. Steps to reproduce the issue: ============================== - Install sales and studio - Open studio in sales and go to reports tabs - Select any report and add a table (3x3 for example) - type anything, it will change the layout of the table (auto increase the size of the cell) Solution: ========= remove `table-layout='auto'` from the css file. task-3749133 Forward-Port-Of: odoo/enterprise#57221
Fixed an issue where translations in reports were lost after editing them with Studio. When users edited a report that had existing translations in multiple languages, those translations would disappear. This fix ensures all translations from the original report are properly preserved and carried over to the edited version.
Original PR description
Have some translations set on a view used by a report. Edit that report with studio. Print the report with a specific language. Before this commit, the terms that were translated before the edition, were not translated after edition. Since commit[1], the whole combined arch of a view is used to make a final inheriting view containing the changes. Unfortunately, translations were in the blind spot of that commit, so that there weren't lost, but simply not copied on the studio view. After this commit, this works as expected as we copy all terms for all languages for all views in the inheritance chain onto the studio view. opw-3746922 opw-3724701 opw-3719157 [1]: b7d0d3034d53cdab831f42f8b37a14cf50f3720e Forward-Port-Of: odoo/enterprise#56781
This fix resolves an access error that prevented users with only Appointment Administrator rights from editing appointments when the CRM integration is enabled. The issue occurred because the system was trying to display sales-related information (lead count) that these users don't have permission to access. The fix restricts this sales information to only users with appropriate sales permissions, allowing all appointment administrators to edit appointments without errors.
Original PR description
Steps to reproduce the issue: - Install `appointment_crm` module - Go to Calendar > Online Appointments - Open `Technical Demo` (for test purpose) - Go to `Options` tab and enable `Create…
Steps to reproduce the issue:
- Install `appointment_crm` module
- Go to Calendar > Online Appointments
- Open `Technical Demo` (for test purpose)
- Go to `Options` tab and enable `Create Opportunities`
- Click on `Preview` button
- Schedule an appointment
- Create another user that have only `Appointment / Administrator` access rights
- Log in with the new user
- Go to Calendar > Online Appointments
- Open `Technical Demo`
Issue:
saas-16.2: Number of lead not displayed in stat button and raise an
access error when clicking on it. saas-16.3+: Access error is raised when trying to edit the appointment.
Cause:
Trying to display a stat button that exploit a field (`lead_count`)
that has a group declared in python (`group_sale_salesman`) while user
not being part of the group and group not declared on the stat button.
Solution:
Don't display button if not leads linked to the appointment.
Add group `group_sale_salesman` on stat button so it is not displayed
if user is not part of the group.
opw-3751444
Forward-Port-Of: odoo/enterprise#57328
Forward-Port-Of: odoo/enterprise#57299This fix resolves an access error that occurred when opening a product catalog from a sales order in a non-primary company. The system now correctly uses the sales order's company context when accessing the catalog, ensuring users can view and manage products specific to their current company without permission errors.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a new company; 2. switch to it via the selector; 3. create a new product specific to the company; 4. create a sale order; 5. open the catalog via a sale order line. Issue ----- Access error Cause ----- The catalog controller loses track of the current company, so `env.company` defaults to the primary `company_id` of the user. Solution -------- Use `with_company` to update `env.company` to the order's company. opw-3690226
This fix ensures that when managing inventory routes across multiple companies, the company assignment remains consistent between routes and their associated rules. Previously, it was possible to assign a route to one company while its rules belonged to different companies, causing data inconsistency. Now the system enforces that routes and their rules must always belong to the same company.
Original PR description
### Steps to reproduce:
- Create two companies:
- (ex. Daughter Company)
- (ex. Mother Company)
- Install **Inventory** app and **stock_dropshipping** module
- In the settings of both companies:
- enable **Multi-Step Routes**
- enable **Dropshipping** option
- Using the **Daughter Company**, go to **Routes** > **Dropship** route
- When You try to set Company to Daughter Company, it's _**possible**_ to do so even thought the rules belonging to the Dropship route belongs to two companies: Daughter Company and Mother Company which is **_NOT_** consistent
### Discuss
- We constraint the route company to always be consistent with the rule(s) company and vice verca
opw-3648535
Forward-Port-Of: odoo/odoo#149894This fix resolves an issue where receipt printing on Android devices was producing blank pages. The problem occurred because the receipt element was being removed too quickly during the printing process. The solution keeps the receipt element available longer, ensuring it prints correctly before being cleaned up.
Original PR description
Prior to this commit, the receipt element was cloned and appended to the render-container for web printing, then deleted after print callback. This approach failed on Android, leading to an empty page, as the cloned element was removed before printing. This commit resolves the issue by retaining the cloned element until the next clone addition to the container, at which point existing elements are removed. opw-3755682 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where canceled attendees' tickets were incorrectly included in the downloadable PDF ticket file during event order checkout. Now only tickets for confirmed attendees are displayed, ensuring customers receive the correct number of tickets matching their actual registration.
Original PR description
Steps to reproduce the issue: - Install `website_event_sale` module - Create an event with a paid ticket - Go to website and register for the event for 2 persons - Go to the cart and remove one of the attendees - Proceed to checkout and confirm the order - On the checkout confirmation page, click on `Download tickets` - Open the downloaded PDF file Issue: Two tickets are displayed in the PDF file. Cause: Not filtering out the canceled attendees. Solution: Display tickets only for `Attended` and `Registred` attendees. opw-3718542
This update fixes the layout of course articles in fullscreen mode by adding proper spacing between the article content and the sidebar. Previously, article text was cramped against the sidebar, making it difficult to read. Now there is clear visual separation for a better learning experience.
Original PR description
Before this commit: - In the fullscreen player, the content of an article from any course stuck to the contents sidebar, leading to a lack of visual separation. After this commit: - Added padding to the article content in fullscreen view. Creating a clear distinction between the content and the sidebar. Task-3748836 Forward-Port-Of: odoo/odoo#154973 Forward-Port-Of: odoo/odoo#154588
A missing character in the survey module's translation pattern was preventing text from displaying correctly to users. This fix restores the proper translation marker so survey content now appears as intended in all supported languages.
Original PR description
A character was left out of the translation pattern, so the text was never displayed correctly to the user. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue where field representations weren't being properly evaluated as strings in certain scenarios, which was causing system errors. This ensures the system handles field data more reliably and prevents unexpected failures in specific use cases.
Original PR description
In some scenarios, it is necessary to evaluate the representation of fields as a string (which triggers issues if this is not the case). Forward-Port-Of: odoo/odoo#155176 Forward-Port-Of: odoo/odoo#154887
This fix ensures that discount descriptions in loyalty programs are translated into the customer's language consistently. Previously, the word "Discount" was being translated into the user's language while the rest of the description was translated into the customer's language, creating an inconsistent experience. The fix reorders the translation logic so all text is translated into the same language.
Original PR description
Current Behavior: - The word "Discount" is translated in the users language unlike the content of the description which is translated into the customer's language Expected behavior: - The word…
Current Behavior: - The word "Discount" is translated in the users language unlike the content of the description which is translated into the customer's language Expected behavior: - The word "Discount" should be translated as the content of the description. Steps to reproduce: - Sales > Product > Discount & Loyalty Create a new loyalty program and add a translation to the reward description. Create a SO for a customer with the same language. Add products to meet the requirements of the loyalty program and click on Promotion. A line is created for the reward, but the word "Discount" is not translated into the customer's language, but the rest of the description is. Cause of the issue: - The translation of the word Discount is done inside a dictionary comprehension using the _ = GettextAlias() method. As a result, 'self' does not appear in the argument 'frame' from which _ guesses the contextual language. https://github.com/odoo/odoo/blob/4125696a630b3d410f17eab5aa65cc333f4cd9cd/odoo/tools/translate.py#L472-L475 Therefore, the language in which the translation happens is the contextual language of the request (user). Fix: - The translation is applied before the dictionary comprehension so that the method "_" correctly guesses the contextual language. opw-3700429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152318
This fix prevents the system from unnecessarily recalculating product costs after an expense has been submitted. The recalculation was causing confusion and creating discrepancies between expense totals and accounting records. Now, once an expense moves past the initial submission stage, the product cost remains stable and consistent with the financial records.
Original PR description
Fix a bug introduced by 67901a4429c69fbba96c32af5d8f58aff54f0be5 When an expense is submitted and for the steps after, there is no need to recompute the product_cost as it may be confusing or generate discrepancies with the account move by changing the totals. task-3580004 Forward-Port-Of: odoo/odoo#155200 Forward-Port-Of: odoo/odoo#141400
A recent change had stopped creating customer records on Stripe for one-time payments, which disabled Stripe's fraud detection system (Radar) from working properly. This fix restores customer record creation for all payments, ensuring fraud detection tools have access to customer information needed to protect transactions.
Original PR description
Following commit ac90aa07, the Customer object was no longer created on Stripe for one-shot (non-recurring) payments made with Stripe. This prevented Radar (Stripe's fraud detection tool) to work effectively as it could not rely on the customer's name and addresses anymore (see https://docs.stripe.com/radar/integration#recommendations). This commit forces the creation of a Customer object even for one-shot payments. opw-3694379 Forward-Port-Of: odoo/odoo#155179
A test in the sales loyalty delivery module was failing because it referenced a product type that is no longer available after a recent code change. The fix updates the test to use a consumable product type instead, ensuring the test runs correctly when the module is tested independently.
Original PR description
Since https://github.com/odoo/odoo/commit/a54c304487429139c08f384d7b2b620b50cf6f83, sale_loyalty_delivery does not depend on stock anymore. So, the type 'product' (and detailed_type) is not added to the selection. The test does not fail on runbot because the module is never tested alone. We should just change it to type 'consu'. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155166
The translation template file for Odoo's base module has been updated to reflect the latest text strings in the system. This ensures that translators have the most current content to work with when localizing Odoo into different languages, improving the quality and completeness of translations across all supported languages.
Original PR description
Export pot of base module Entreprise: https://github.com/odoo/enterprise/pull/57503
Fixed an issue where the payment form interface would remain locked when errors occurred during the payment process. The system now properly unlocks the user interface when errors are encountered, allowing customers to retry their payment or take other actions without being stuck on a frozen screen.
Original PR description
In some cases, in the payment process we may have errors, and `_enableButton` will be called, but in the new v17 function, this function has a parameter to unblock the UI. In scenarios when the UI is blocked, we should unblock the UI too. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr