Monday, February 26, 2024
25 changes · saas-17.1
Enhancements to existing features
This update changes how product documents are ordered in Odoo, prioritizing them by name instead of ID. This gives users greater control over the appearance of documents in the eCommerce storefront and PDF quotation builder, ensuring the most relevant documents are displayed first.
Original PR description
Ordering documents attached to a produt by name, rather than ID. That allows a control on the order in the PDF quotation builder, and the eCommerce page. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154961
This update adjusts the layout of the Point of Sale (POS) menu to place 'Close Session' and 'Backend' options at the bottom. This change enhances usability by grouping less frequently used functions together, making it easier for staff to find essential controls.
Original PR description
-Move menu options to have 'Close session' and 'Backend' at the bottom of the list task id: 3759943 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#154998
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
Features or functions removed from Odoo
This update removes integrations for payment methods that were not fully supported, specifically Amazon Pay with Adyen and BLIK with Stripe. These removals streamline the system and ensure we're only offering reliable payment options to our customers.
Original PR description
The following combinations of payment methods and providers are removed: - Amazon Pay - Adyen: The payment method cannot be activated because it requires saving a public key in Odoo, and no field was made available for that. Also, a custom configuration is necessary and the public key must be generated through a lengthy process that is too cumbersome for the added value of the payment method anyway. - BLIK - Stripe: The payment method is not supported by Stripe when the PaymentIntent object is created after collecting the payment details. See https://stripe.com/docs/payments/accept-a-payment-deferred?platform=web&type=payment#enable-payment-methods opw-3736511 Forward-Port-Of: odoo/odoo#153481
Code cleanup and technical improvements
This update simplifies the process of adding extra information to stock move lines during the unbuild process. Previously, developers needed to completely replace a core function, but now it's easier to extend and customize this process, allowing for more adaptable stock management. This change enhances the system's flexibility and reduces development effort.
Original PR description
With the current design, when we want to pass more parameters from the original move lines of MO to the unbuild move lines, we can't easily extend action_unbuild() and it seems we need to completely override it. After this refactoring commit, developers can easily extend and add more parameters. @qrtl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154667 Forward-Port-Of: odoo/odoo#151983
Miscellaneous changes
Have a SA company In Accounting settings activate invoice terms Add a payment terms string in english, add the arabic translation Create an invoice Click preview Issue: Payment terms will be shown in english twice This occurs because, even if `narration` field is translatable the translation is not automatically copied when the field is copied from the company `invoice_terms`. opw-3530811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-p
Original PR description
Have a SA company In Accounting settings activate invoice terms Add a payment terms string in english, add the arabic translation Create an invoice Click preview Issue: Payment terms will be shown in english twice This occurs because, even if `narration` field is translatable the translation is not automatically copied when the field is copied from the company `invoice_terms`. opw-3530811 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153139 Forward-Port-Of: odoo/odoo#138949
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
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
Description of the issue/feature this PR addresses: The sales team specified on res.partner is not reflected with the partners' change. Current behavior before PR: If a new partner is chosen on sale.order, the sales team remains the same. Desired behavior after PR is merged: sales team on sale.order is chosen accordingly if specified on res.partner --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147231 Forward-
Original PR description
Description of the issue/feature this PR addresses: The sales team specified on res.partner is not reflected with the partners' change. Current behavior before PR: If a new partner is chosen on sale.order, the sales team remains the same. Desired behavior after PR is merged: sales team on sale.order is chosen accordingly if specified on res.partner --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#147231 Forward-Port-Of: odoo/odoo#145670
### Steps to reproduce: 1. install the calendar module 2. in General settings, add the French -or any- language 3. create a new event 4. under **Options** tab choose the recurrence type to be weekly 5. select the days to repeat the event on 6. save the event 7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English ### Investigation - the translation is applied on the model level, not on the code l
Original PR description
### Steps to reproduce: 1. install the calendar module 2. in General settings, add the French -or any- language 3. create a new event 4. under **Options** tab choose the recurrence type to be weekly…
### Steps to reproduce:
1. install the calendar module
2. in General settings, add the French -or any- language
3. create a new event
4. under **Options** tab choose the recurrence type to be weekly
5. select the days to repeat the event on
6. save the event
7. send an email using the **EMAIL** button, you can notice that works like (Weeks) and the days’ names are not translated but still in English
### Investigation
- the translation is applied on the model level, not on the code level. So we have to explicitly/programmatically translate the options.
### Discussion
- In the proposed fix, we compute the recurrence rule `name` by translating it to the current language -the event creator's language- but as this field is **stored**, it resulted in another issue that the invitation emails sent to the participants had a mix of languages: the email template being translated in each participant's language while the recurrence rule itself is translated in the owner's language being a **stored** field
- That's why the fix got extended to embed translating of the recurrence rule directly into the template.
- However there's a **_limitation_** we couldn't deal with that's there are two types of emails we are concerned with:
- invitation emails that follows `calendar attendee` model which works correctly as discussed
- update emails that follows `calendar event` model coming from the composer which deosn't allow to properly use partners/participants languages
### Resolution
- The update emails are sent in the owner's language, with the intention to enhance the behavior in master (Task-3677327)
opw-3483319
Forward-Port-Of: odoo/odoo#151669
Forward-Port-Of: odoo/odoo#141951Issue: ====== 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
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
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, t
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
The o_field_image in the Drinks in the form view is cancelling the negative margin applied by the row class on the o_group. Using a gutter-x 0 on the o_group removes the padding allowing the inputs to be aligned with the title. This is a quickfix and the behavior of the o_field_image in a form view should be reviewed consistently across Odoo because different module seems to use their own fix for this (Ref: new task-3584778) task-3584529 | Before | | :--: | |  task-3584529 | Before | | :--: | |  | After | |  | Forward-Port-Of: odoo/enterprise#50265
### 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 p
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 Forward-Port-Of: odoo/enterprise#55850
Before this commit, when the gantt view displays the current week, let's say from `2024-18-02` to `2024-24-02` and the planned dates of one pill is: - `start_datetime`: `2024-17-02 16:00:00` - `end_datetime`: `2024-18-02 00:00:00` (the end datetime of the pill should be the first column displayed in the gantt view), a traceback is occurred because the pill will not be displayed in the gantt view and so the grid column for that pill will be 0 and since the split tool uses the grid column for ea
Original PR description
Before this commit, when the gantt view displays the current week, let's say from `2024-18-02` to `2024-24-02` and the planned dates of one pill is: - `start_datetime`: `2024-17-02 16:00:00` - `end_datetime`: `2024-18-02 00:00:00` (the end datetime of the pill should be the first column displayed in the gantt view), a traceback is occurred because the pill will not be displayed in the gantt view and so the grid column for that pill will be 0 and since the split tool uses the grid column for each pill to place the different scissor to enable the split tool for the pills displayed on more than one column in the gantt view. This commit makes sure the split tool will skip the pill with column less than 1 to be sure `pill.grid.column[0] - 1` uses to create a array will not be less than 0. opw-3705995 closes #55807 Forward-Port-Of: odoo/enterprise#57482
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
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
The file `test_ui` is currently not imported. The tour is pretty useless and has been improved in 17.0. We will keep it in that version, to be sure that we don't break the equivalent tour, but we can remove in these versions (it just creates a sample bill and post it, currently). The tour `account_accountant_tour_upload_ocr_step` has been deemed useless. It pops a bubble on a button where it makes no sense, with a self-explanatory message already. Forward-Port-Of: odoo/enterprise#5722
Original PR description
The file `test_ui` is currently not imported. The tour is pretty useless and has been improved in 17.0. We will keep it in that version, to be sure that we don't break the equivalent tour, but we can remove in these versions (it just creates a sample bill and post it, currently). The tour `account_accountant_tour_upload_ocr_step` has been deemed useless. It pops a bubble on a button where it makes no sense, with a self-explanatory message already. Forward-Port-Of: odoo/enterprise#57225 Forward-Port-Of: odoo/enterprise#56726
Fixes that sale_subscription mail templates is reverted on module upgrade When upgrading the sale_subscription module all subscription email templates was reverted due to missing noupdate=1 Forward-Port-Of: odoo/enterprise#57043
Original PR description
Fixes that sale_subscription mail templates is reverted on module upgrade When upgrading the sale_subscription module all subscription email templates was reverted due to missing noupdate=1 Forward-Port-Of: odoo/enterprise#57043
**Issue:** The total amounts div overlaps the digital stamp from the Mexican localization **Solution:** Put the digital stamp at the final of every element of the invoice to avoid the overlapping **opw-3742996** Forward-Port-Of: odoo/enterprise#56718
Original PR description
**Issue:** The total amounts div overlaps the digital stamp from the Mexican localization **Solution:** Put the digital stamp at the final of every element of the invoice to avoid the overlapping **opw-3742996** Forward-Port-Of: odoo/enterprise#56718