Monday, February 26, 2024
12 changes · saas-17.1
Resolved issues and error corrections
This update fixes an issue where the Point of Sale system incorrectly parsed decimal numbers (like '0,5'). The fix ensures that prices are interpreted correctly based on the system's decimal separator setting, preventing miscalculations and ensuring accurate order totals. This improves the reliability of sales transactions.
Original PR description
After commit 28b7d698be8255f933ba5314e44e7059746fc234, some part of the code moved to a new file. However, the `parseFloat` that was imported from web wasn't imported. This caused the default parseFloat to be used, which doesn't consider the system "Decimal Separator". As a result, it would parse "0,5" as zero. opw-3754496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a reporting issue where the BoM overview only showed stock in the subcontracting location. Now, warehouse stock is also included in the calculations for free quantity and on-hand quantity, providing a more accurate view of available materials. This ensures better production planning and inventory management for subcontracted products.
Original PR description
### Current behavior before PR In BoM overview report, the free quantity and the on hand quantity only reflected the available stock in subcontracting location ### Desired behavior after PR is merged - Selected warehouse stock is also included in the calculation. - The free to produce quantity was calculated based on the available stock in the warehouse in addition to the subcontracting location. For this reason, `free_to_manufacture_qty` variable was introduced. If it is a non-subcontracting BoM, it will be equal to the free quantity available in warehouse stock. Otherwise, it will contain only the stock in the subcontracting location. **task-3632211** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#145889
This update adjusts the type definition for the `_t` function in the Odoo web module. While technically correct, the change introduced a compatibility issue with existing code. The previous definition was also valid as `LazyTranslatedString` is a type of `String`. This fix ensures continued compatibility and stability of the translation system.
Original PR description
Commit 0493f5d6aa changed the return type of `_t`
from `@returns {string}` to `@returns {string|LazyTranslatedString}`.
While it's not wrong, it breaks other function types which do not care (and should not care) about lazy translated string.
And the previous return type was also correct since `LazyTranslatedString` extends `String`. A return type which is stricter than what's actually returned is always correct.
consider the following function:
```js
/**
* @returns {string}
*/
function myStringFunction() {
...
return _t("a string")
}
```
Since commit 0493f5d6aa, the type is wrong:
`Type 'LazyTranslatedString' is not assignable to type 'string'`
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the 'removeFormat' button in the web editor didn't fully clear text styles (like background and text color). Now, the button completely removes all formatting, ensuring text appears without any lingering styles. This improves the editor's functionality and user experience.
Original PR description
**Before this PR:** When using the removeFormat button, the backgroundColor and foregroundColor were not completely removed. **After this PR:** The removeFormat button will completely remove all the styles applied to it. **task-3344762** Forward-Port-Of: odoo/odoo#130670
This update resolves a minor issue in the Data Recycle module's testing process. Previously, tests relied on an outdated field in the partner record that no longer exists. This change updates the tests to use a different model, ensuring accurate and reliable test results. This ensures the Data Recycle functionality continues to operate correctly.
Original PR description
Since https://github.com/odoo/odoo/pull/112769, there isn't date field on res.partner, but there are still some tests using it (TestDataRecycle). Fix the test by using a other model.
This update fixes an issue where course articles in fullscreen mode were visually blended with the sidebar, making them difficult to read. Padding has been added to the article content, creating a clearer separation and improving the overall user experience. This ensures articles are easily visible and understandable in fullscreen course views.
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
This update corrects a technical issue where Odoo struggled to consistently handle field data as strings in certain situations. This fix ensures data is represented correctly, preventing potential errors and improving the reliability of Odoo's core functionality. It's a routine maintenance update focused on data integrity.
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 update fixes an issue where loyalty reward descriptions weren't being translated into the customer's language. Now, the 'Discount' label and all other text within loyalty program descriptions will be displayed in the customer's preferred language, ensuring a consistent and localized experience for users.
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 update corrects a recent change that prevented the creation of customer records for one-time Stripe payments. This was impacting Stripe's fraud detection system (Radar), which relies on customer information. The fix ensures accurate customer data is created, improving payment security and functionality.
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 minor issue in the sale loyalty delivery module was causing a test failure. This change corrects a configuration error related to product type definitions, ensuring the module functions correctly. The fix simplifies the test setup and ensures accurate results.
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
This update resolves an issue where sales order prices were being recalculated unexpectedly due to floating-point precision problems. The fix temporarily prevents the system from recomputing prices based on the quantity field, ensuring accurate pricing calculations. This improves the reliability of sales order processing.
Original PR description
Steps to reproduce * Create a new SO * Add a new line with a storable product and 15.12 as quantity * change the price to X * Save and confirm * Set a scheduled date (Other info tab) * Save -> The price of the SOL is recomputed. Cause Because of floating point issues, the value returned by the onchange for the product_uom_qty field is 15.1200000....1, therefore being considered in the client-side as having been changed by the onchange. The value is then sent to the server on save, triggering a recomputation of the SOL prices. Until there is a clear solution in the framework, this commit drops 'unmodified values' for the product_uom_qty field, using an existing check, and only if there is only one updated line in the write call. opw-3670318 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155271
This update clarifies the settings within Odoo's alias domains, making them easier for users to understand and manage. Specifically, advanced configuration options like bounce and catchall addresses are now visible in debug mode, allowing for careful adjustments. Tooltips have also been added to guide users on how to use these fields effectively.
Original PR description
Ease understanding the purpose of main fields on alias domains. Set bounce, catchall and default_from available in debug mode as those are advanced configuration bits that should be displayed (and modified) with care. Task-3696224 Forward-Port-Of: odoo/odoo#150401