Odoo Changelog — 2022-04-19

Tuesday, April 19, 2022

46 changes · master

Improvements(9)

Enhancements to existing features

[IMP] web,*: update templates to owl 2

Coremasteraccountbase_automationbase_importboardgoogle_drivegoogle_spreadsheethr_holidayshr_holidays_attendanceiapl10n_ae_posl10n_co_posl10n_fr_pos_certl10n_gcc_posl10n_in_posl10n_sa_posmail

This change updates many Odoo screen and widget templates to the newer Owl 2 format. It helps keep the user interface framework current and prevents older templates from becoming unsupported in future releases.

Original PR description

From now on, Owl will only accept owl 2 templates. Old templates
will be considered old, and should be retired from active service.

Note that this commit uses the simple "2" value, but you can use a more
interesting expression. For example, owl="1+1"

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

#templates#ui#compatibility#owl2

[IMP] website_slides: adapt message if user gets 0xp

PR #86497

Coremasterwebsite_slides

Quiz takers will no longer see an awkward message saying they earned 0 XP after completing a quiz. When no XP is awarded, the site now shows a simple completion message, making the experience clearer and more polished.

Original PR description

Purpose
=======
Avoid showing "Amazing! You earned 0xp".

Task-2790997

#quiz#eLearning#user experience

[IMP] mail: introduce NotificationGroupView/markAsReadRef

PR #88712

Coremastermail

Mail notifications now use a clearer internal structure for grouping and marking messages as read. This helps make notification behavior more reliable and easier to maintain, with minimal direct change for users.

Original PR description

Task-2579306

#notifications#mail#read-status

[IMP] mail: introduce ThreadPreviewView/markAsReadRef

PR #88811

Coremastermail

The mail app now has a cleaner way to manage message thread previews and mark them as read. This supports a smoother inbox experience and helps keep the underlying messaging interface easier to maintain.

Original PR description

Task-2579306

#mail#messages#thread previews

[IMP] mail: introduce ThreadNeedactionPreviewView/markAsReadRef

PR #88798

Coremastermail

The mail app now has a cleaner way to manage preview entries for conversations that need attention, including marking them as read. This improves consistency in how unread items are tracked and prepared for display, supporting a smoother messaging experience.

Original PR description

Task-2579306

#mail#messages#inbox#read-status

[IMP] mail: introduce ThreadView/onFocusin

PR #88821

Coremastermail

The mail app now handles focus changes within conversation views more consistently, including when chat windows are involved. This should make navigating and interacting with messages feel smoother and more reliable for users.

Original PR description

Task-2579306

#mail#chat#usability

[IMP] mail: introduce AutocompleteInputView/placeholder

PR #88931

Coremastermail

The mail app now has a reusable autocomplete input view with placeholder support. This makes search and selection fields in chat and messaging areas more consistent and easier to understand for users.

Original PR description

Task-2817076

#mail#autocomplete#messaging#usability

[IMP] mail: move component handlers to models (step 6)

PR #89076

Coremastermail

Mail-related interaction handling was moved into shared mail models instead of being kept in individual screen components. This is an internal maintainability improvement that should make future mail changes easier and more reliable without changing day-to-day user workflows.

Original PR description

This commit moves some handler methods from components to models,
as a step closer to having most of business code in models.

Having business code in models is desirable so that the code is much more maintainable:
easier to change and more robust code.

Task-2579306

#mail#maintainability#internal

[IMP] mail: introduce AutocompleteInputView (step 2)

PR #89077

Coremastermail

The mail app's autocomplete input has been reorganized so more of its behavior is handled in the shared data model rather than the screen component. This internal improvement makes the messaging code easier to maintain and evolve, with little expected change for end users.

Original PR description

This commit moves some business logic from component AutocompleteInput
To model AutocompleteInputView, as a step to move further to having essentially
all business code in models.

Having code in models is desirable to have very maintainable code, thanks to
robust and declarative code with an ORM-like architecture.

Task-2817076

#mail#autocomplete#maintainability

Bug Fixes(1)

Resolved issues and error corrections

[FIX] hr_timesheet: properly display recorded hour in button

PR #88544

Coremasterhr_timesheet

Project pages now show recorded timesheet hours in the correct hour or day format. This helps users review project time totals accurately without being misled by incorrect conversions.

Original PR description

before this commit, the recorded hours are not correctly
computed on the project.project form view

so this commit fixes the issue by correctly computing recorded hours
so that the project.project form view contains the correct recorded hour

task-2788878

#timesheets#projects#recorded hours

Refactoring(3)

Code cleanup and technical improvements

[REF] mail: `MessageAuthorPrefix`, review and simplify scss

PR #89002

Coremastermail

This update simplifies the styling behind message author prefixes in Odoo's Mail app as part of a broader interface cleanup. It should help keep the messaging interface easier to maintain while preserving the existing user experience.

Original PR description

Part of the overall v16 SCSS optimization/restyle, task-2704984

task-2826482

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#scss#messaging#ui-cleanup

[REF] mail: `discuss_mobile_mailbox_selection` scss refactoring

Other(33)

Miscellaneous changes

[FW][FIX] account: Fix reconciliation rounding issue

PR #88265

Coremasteraccount

Original PR description

Steps to reproduce:
- Create an invoice: select a product; set the price to 23.00$; change the currency to €; confirm the invoice.
- Create a receiving payment from the same customer: select the $ currency and put 100$
- Go back to the invoice and select the payment/reconcile the invoice and the payment.

Issue:
Residual of 0.01€ to pay on the invoice.

Cause:
(conversion rate: 1.5289$/1€)

1) When the currency is changed or the price assigned, we convert the price EXCL. and then we convert the tax amount.

https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L3953-L3954

In our example:
- price EXCL.: 23€ * 1.5289 = 35.1647$
    price._convert() -> 35.16$
- Tax amount: 3.45€ * 1.5289 = 5.274705$
    tax_amount._convert() -> 5.27$
Real Sum = 40,439405$
Sum returned after convertion = 40.43$ != 40.44$

2) To compute what is left to be paid, we use the converted amount and convert it back to the currency of the invoice. Double conversion, double mistake.

https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L4873-L4878

In our example:

3) We convert back the 40.43$ to know the residual:
- 40.43$ / 1.5289 = 26.443848519€ => rounded = 26.44€ != 26.45

We then compute the `debit_amount_residual_currency` (26.45€) by substracting from it the `min_debit_amount_residual_currency`(26.44€).

https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L4886-L4887

Which lefts us with a `debit_amount_residual_currency` 0.01€ (0.0099999..801).
https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L1421-L1437

ticket: 2765223

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#88166
Forward-Port-Of: odoo/odoo#87963

From now on, Owl will only accept owl 2 templates. Old templates will be considered old, and should be retired from active service. Note that this commit uses the simple "2" value, but you can use a more interesting expression. For example, owl="1+1" 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

This commit moves some handler methods from components to models, as a step closer to having most of business code in models. Having business code in models is desirable so that the code is much more maintainable: easier to change and more robust code. Task-2579306

This commit moves some business logic from component AutocompleteInput To model AutocompleteInputView, as a step to move further to having essentially all business code in models. Having code in models is desirable to have very maintainable code, thanks to robust and declarative code with an ORM-like architecture. Task-2817076

before this commit, the recorded hours are not correctly computed on the project.project form view so this commit fixes the issue by correctly computing recorded hours so that the project.project form view contains the correct recorded hour task-2788878

Steps to reproduce: - Create an invoice: select a product; set the price to 23.00$; change the currency to €; confirm the invoice. - Create a receiving payment from the same customer: select the $ currency and put 100$ - Go back to the invoice and select the payment/reconcile the invoice and the payment. Issue: Residual of 0.01€ to pay on the invoice. Cause: (conversion rate: 1.5289$/1€) 1) When the currency is changed or the price assigned, we convert the price EXCL. and then we convert the tax amount. https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L3953-L3954 In our example: - price EXCL.: 23€ * 1.5289 = 35.1647$ price._convert() -> 35.16$ - Tax amount: 3.45€ * 1.5289 = 5.274705$ tax_amount._convert() -> 5.27$ Real Sum = 40,439405$ Sum returned after convertion = 40.43$ != 40.44$ 2) To compute what is left to be paid, we use the converted amount and convert it back to the currency of the invoice. Double conversion, double mistake. https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L4873-L4878 In our example: 3) We convert back the 40.43$ to know the residual: - 40.43$ / 1.5289 = 26.443848519€ => rounded = 26.44€ != 26.45 We then compute the `debit_amount_residual_currency` (26.45€) by substracting from it the `min_debit_amount_residual_currency`(26.44€). https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L4886-L4887 Which lefts us with a `debit_amount_residual_currency` 0.01€ (0.0099999..801). https://github.com/odoo/odoo/blob/582b43bdf46c485be8219e1cbeb60dbed033f1e7/addons/account/models/account_move.py#L1421-L1437 ticket: 2765223 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88166 Forward-Port-Of: odoo/odoo#87963

[VIDEO](https://drive.google.com/file/d/1Y2NxmGZvVJ_s7MBNGIbkSNk5B4qbbGEH/view) ## Description of the issue/feature this PR addresses: _get_payment_method_codes_to_exclude is not being used on _compute_payment_method_line_id ## Current behavior before PR: 1. Create a bank journal with only with incoming payment method "SEPA Direct Debit" 2. Create a customer payment: choose journal = the new bank 3. Set "internal transfer = True" 4. change payment_type to "send" and then to "receive" (to force _compute_payment_method_line_fields recomputation) 5. "SEPA Direct Debit" is selected on "Payment Method" but it's not a selectable value (try to choose again manually) ## Desired behavior after PR is merged: * Payment Method should be empty ## Changes on this PR 1. _get_payment_method_codes_to_exclude was not considered on _compute_payment_method_line_id 2. to avoid duplicating code on _compute_payment_method_line_id we can directly call available_payment_method_line_ids 3. to avoid re-defining dependencies (and make inheritance easier) we can use 'available_payment_method_line_ids' on _compute_payment_method_line_id 4. fix docstring, _compute_payment_method_fields does not exists anymore, it's called _compute_payment_method_line_fields 5. fix using "self" instead of pay when calling _get_payment_method_codes_to_exclude ## FIX on enterprise Another fix proposed on enterprise: https://github.com/odoo/enterprise/pull/26127 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88444

**Steps to reproduce the bug:** - Create the workcenter_1: - Time Efficiency: 100% - Capacity: 2 - Setup Time: 1 - Cleanup Time: 1 - Create the workcenter_2: - Time Efficiency: 100% - Capacity: 4 - Setup Time: 10 - Cleanup Time: 5 - Alternative Work centers: **workcenter_1** - Create a storable product “**P1**” with BOM: - Add any product as component - Add operation: - Duration: 60 - Work center: Workcenter_2 - Create a MO: - select “P1” as Product - Qty to produce: 4 - Confirm and Plan **Problem:** The workcenter_1 is chosen while work_center_2 is faster it can manufacture the 4 units at the same time while workcenter_1 must do two cycles As the Time Efficiency = 100%, so: _Total duration_ = (Setup Time + Cleanup Time) + duration_by_unit * nb_cycle _Work_center_1_ = (1 + 1) + 60 * 2 = 122 _Work_center_2_ = (10 + 5) + 60 = 75 The calculation is bad because we use the number of cycles necessary for the work_center defined in the BOM in the calculation for the alternative work center opw-2821749 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#88917 Forward-Port-Of: odoo/odoo#88808

If the user triggers several orderpoints one by one, some purchase order lines may be merged while they shouldn't. To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Create a product P: - Type: Storable - With a vendor V - Route: Buy 3. Add two reordering rules to P: - Min=Max=1 at WH/Stock - Min=Max=2 at WH/Stock/Shelf 1 4. Inventory > Operations > Replenishment, trigger the orderpoints of P (one by one) 5. Open the generated PO Error: There is only one line with 3 x P, there should be two lines (1 x P + 2 x P, one for each orderpoint). If the user confirms the PO and receives the products, the destination location will be Stock or Shelf 1 (depending on the last orderpoint triggered) Running the orderpoint leads to `_run_buy`, where we try to find an existing PO line so we can update it (else we will create a new one): https://github.com/odoo/odoo/blob/5b34adb51eda978aa9ef1a434ab77257d73b9594/addons/purchase_stock/models/stock_rule.py#L122-L129 Here is the issue: the filter in `_find_candidate` contains an `or True` that makes a whole condition useless. Considering [1], the condition on `move_dest_ids` is only relevant when an orderpoint is defined. Therefore, we can remove the `or True` and improve the condition [1] 63fffa0beeb83f1cb857929959e72ff72a481304 OPW-2720868 Forward-Port-Of: odoo/odoo#88870

In some cases, it is not possible to produce a tracked product that has been used as a component of another product. To reproduce the issue: 1. Create three products A, B, C: - A storable - B storable and tracked by lot - C consumable 2. Update on-hand qty of B - 10 x lot L01 - 5 x lot L02 3. Create two bills of materials - Product: A - Components: 1 x B - Product: B - Components: 1 x C 4. Produce 15 x A (MO01) - Note: it should use 10 L01 and 5 L02 5. Produce 15 x B with lot L03 (MO02) Error: When marking MO02 as done, a user error is displayed: "Cannot set the done quantity from this stock move, work directly with the move lines." The user should be able to mark the MO as done. When confirming MO02, it confirms the associated SMs. Since the conditions are respected, we then try to assign both consumed and finished moves. This is the issue, we should not try to assign the finished move. Indeed, because of this, at some point it leads to `_update_reserved_quantity`: https://github.com/odoo/odoo/blob/9e5f76a759640e1072560a60c6e3d608296d7feb/addons/stock/models/stock_move.py#L1355-L1360 We try to reserve some quants in the production location. Thanks to step 4, two quants (L01 and L02) are available. As a result, two SMLs are created. Lastly, when marking MO02 as done, since the user has not defined the done quantity on each SML, the error is raised. We should prevent the finished move to be assigned. OPW-2752436 Forward-Port-Of: odoo/odoo#88944 Forward-Port-Of: odoo/odoo#88668

Improvements(9)

[IMP] web,*: update templates to owl 2

[IMP] website_slides: adapt message if user gets 0xp

[IMP] mail: introduce NotificationGroupView/markAsReadRef

[IMP] mail: introduce ThreadPreviewView/markAsReadRef

[IMP] mail: introduce ThreadNeedactionPreviewView/markAsReadRef

[IMP] mail: introduce ThreadView/onFocusin

[IMP] mail: introduce AutocompleteInputView/placeholder

[IMP] mail: move component handlers to models (step 6)

[IMP] mail: introduce AutocompleteInputView (step 2)

Bug Fixes(1)

[FIX] hr_timesheet: properly display recorded hour in button

Refactoring(3)

[REF] mail: `MessageAuthorPrefix`, review and simplify scss

[REF] mail: `discuss_mobile_mailbox_selection` scss refactoring

Other(33)

[FW][FIX] account: Fix reconciliation rounding issue

Improvements(9)

[IMP] web,*: update templates to owl 2

[IMP] website_slides: adapt message if user gets 0xp

[IMP] mail: introduce NotificationGroupView/markAsReadRef

[IMP] mail: introduce ThreadPreviewView/markAsReadRef

[IMP] mail: introduce ThreadNeedactionPreviewView/markAsReadRef

[IMP] mail: introduce ThreadView/onFocusin

[IMP] mail: introduce AutocompleteInputView/placeholder

[IMP] mail: move component handlers to models (step 6)

[IMP] mail: introduce AutocompleteInputView (step 2)

Bug Fixes(1)

[FIX] hr_timesheet: properly display recorded hour in button

Refactoring(3)

[REF] mail: `MessageAuthorPrefix`, review and simplify scss

[REF] mail: `discuss_mobile_mailbox_selection` scss refactoring

Other(33)

[FW][FIX] account: Fix reconciliation rounding issue

[REF] mail: `MessageActionList`, review and simplify scss

[FW][FIX] account_payment: hide payment methods

[FW][FIX] l10n_it_edi: wrong condition for contact form vat

[FW][FIX] stock: display the date in the breadcrumb

[FW][FIX] mrp: use the fastest workcenter

[FW][FIX] purchase_stock: create new POL if different RR

[FW][FIX] mrp: compute state thanks to float_compare

[FW][15.0][FIX] Duplicate some mail.thread.phone code in res.partner

[FW][FIX] mail: mass mailing to same mail adress

[FW][FIX] l10n_ar: Gross Income fields in form view

[FW][FIX] mail: ensure a user can leave a private channel + test

[FW] pos loyalty fixes

[FW][IMP] point_of_sale: make _onDoRefund overrideable

[FW][FIX] point_of_sale: access error when limited partners

[FW][FIX] mrp: produce a tracked and manufactured component

[FW][FIX][15.0] hr_timesheet, sale_timesheet: Fix project user cannot access Project app

[FW][FIX] mail: prevent incorrect loading of settings from the localstorage

[FW][FIX] web: update owl to last version

[FW][FIX] mail: fix compute of isMobileDevice

[FW][FIX] mail: properly refresh chatter on attachment deletion

[FW][FIX] website_forum: avoid error when the sort param is encoded

[FW][FIX] mail: limit reply-to name part

[FW] Reorder forum faq by elm

[FW][FIX] l10n_ar_reports: UnicodeEncodeError error

[FW][FIX] l10n_cl_edi_boletas, l10n_cl_edi_stock: add locking to avoid se…

[FW][IMP] account_reports: only fetch currency when necessary

[FW][FIX] account_bank_statement_import_qif: not required field

[FW][FIX] account_budget : fix budget suggestion

[FW][FIX] website_sale_account_taxcloud : pay right taxes

[FW][FIX] hr_expense_predict_product: limit product prediction to active products

[FW][FIX] account_batch_payment: fix wizard access rights

[FW][FIX] l10n_cl_edi_boletas: fix render parameter

[FW][FIX] _sepa_direct_debit: compute payment methods