Odoo Changelog — 2023-12-01

Friday, December 1, 2023

58 changes · master

Improvements(4)

Enhancements to existing features

[IMP] mail, *: move tests post install

Coremastercrm_livechatim_livechattest_mailwebsite_livechatmail

This update moves mail and live chat related tests to run after installation, allowing automated builds to run them in parallel and complete faster. It also improves test coverage by checking the full installed application setup and tidies test file organization for easier maintenance.

Original PR description

\* = crm_livechat, im_livechat, test_mail, website_livechat The opportunity is taken to clean up and standardize headers/imports. - clean up obsolete # at the top of files - regroup imports from…

\* = crm_livechat, im_livechat, test_mail, website_livechat

The opportunity is taken to clean up and standardize headers/imports.

- clean up obsolete # at the top of files
- regroup imports from `odoo.tests` all together, apply import guidelines, remove unused imports
- always have tagged usage with double quote, and in this order: test specific tags, post_install, -at_install

Performance
-----------
Post-install tests are parallelized on runbot, allowing to reduce build times.

Before/after

mail: 18.81s -> 0s
test_mail: 113.7s -> 2.53s

With this PR 130s can be gained on each runbot build with splits.

Coverage
--------
Post-install tests cover the full application (with all overrides installed) rather than a particular sub-set of the code.

Tests of sub-set of the code are desirable too, but they are already tested with single-app builds on runbot.

Maintenace
----------
Post-install tests are easier to maintain and to run, as dropping the database and installing it again is not necessary to run them.

#testing#performance#maintenance

[IMP] sale: suggest customer as follower

PR #144200

Coremastersale

Sales orders now suggest adding the customer as a follower when a message is sent in the chatter, if they are not already following. This helps keep customers included in relevant communication and reduces the chance of missed updates.

Original PR description

Suggest the customer as a follower (if not already the case) when sending a message in the chatter.

task-3246613

#sales#communication#customer-followup

[IMP] sale: downpayment btn switch btn group

PR #138084

Coremastersale

The customer portal down payment choice now looks and behaves more like a standard switch. This makes the payment selection clearer for customers and improves the checkout experience without changing the underlying payment process.

Original PR description

The downpayment option on portal doesn't look like a switch.
this commit transform the buttons into the default btn-group component
to act like a regular switch.

However since the page needs to refresh, we have to apply the classes
manually with a switch triggering the checked attribute to obtain the expected visual result.

task-3499055

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

#portal#down payment#user experience

[IMP] website_sale_*: adapt to community changes

PR #45427

Enterprisemasterwebsite_sale_account_taxcloudwebsite_sale_external_taxwebsite_sale_rentingwebsite_sale_stock_renting

This update aligns enterprise e-commerce rental and tax-related checkout components with recent core platform changes. It keeps delivery returns, cart updates, and external tax integrations using the right underlying behavior, reducing maintenance risk and helping checkout flows remain reliable.

Original PR description

* Additional cleanup/improvements

Community PR: https://github.com/odoo/odoo/pull/131184

#ecommerce#rentals#checkout#tax

Refactoring(4)

Code cleanup and technical improvements

[IMP] website_sale*: little improvements/cleanups

PR #131184

Coremasterwebsite_salewebsite_sale_comparisonwebsite_sale_loyaltywebsite_sale_pickingwebsite_sale_stock

This update reorganizes and cleans up the website shop and checkout code to make it easier to maintain. It focuses on internal quality, consistency, and validation around shopping, delivery, payment, reordering, comparison, loyalty, pickup, and stock-related shop flows, with little direct change expected for end users.

Original PR description

Enterprise PR: https://github.com/odoo/enterprise/pull/45427

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

Other(50)

Miscellaneous changes

[FW][FIX] calendar: trigger activity according to timezone

PR #144376

Coremastercalendar

Original PR description

Steps to reproduce: ------------------- - be in UTC -5 (America/Lima for example) on the system (and so browser) and the user profile; - create an event from 4pm to 5pm the next day; - be at 2pm…

Steps to reproduce:
-------------------
- be in UTC -5 (America/Lima for example) on the system (and so browser) and the user profile;
- create an event from 4pm to 5pm the next day;
- be at 2pm today;

Issue:
------
We have a notification in activities for this
event today, which is one day too soon.

Cause:
------
To find the events that need to be notified to the user, we use a domain which, in this case, can be expressed as follows:
```
(
the `start` of the event must be after "now" (the event has not yet passed)
OR
the event `stop` must be after now (the event is in progress)
)
AND
the `start` of the event must be less than the end of the day (the event must be today)
```

The end of the day must be determined, but taking into account the user's timezone. As the domain has to work with UTC values (because the `start` and `stop` values of the event are in UTC in DB), in order to determine the end of the current day, we first need to determine which day the user is in UTC.

Logic before this commit (using the example):
```py
start_dt = datetime.datetime.utcnow() # 19:00 (because 14h in America/Lima -5)
start_date = timezone(tz).localize(start_dt).astimezone(UTC).date() # 00:00 next day
end_dt = datetime.datetime.combine(start_date, datetime.time.max) # 23:59 next day
end_dt = timezone(tz).localize(end_dt).astimezone(UTC) # 4:59 second next day
```
The result (for an America/Lima timezone) is that if the event has its `start` in UTC before 4:59 two days later, the event will be notified.

Solution:
---------
Correct the values used to construct the domain.

Logic after this commit (using the example):
```py
start_dt_utc = now_utc.replace(tzinfo=UTC) # 19:00 (because 14h in America/Lima -5)
start_dt = start_dt_utc.astimezone(user_tz) # 14:00 (because 14h in America/Lima -5)
stop_dt = datetime.datetime.combine(start_dt.date(), datetime.time.max).replace(tzinfo=user_tz).astimezone(UTC) # 4:59 next day
```
Because 23:59 today using user timezone and then converted to UTC gives 4:59 next day. In fact, the day of a user in the America/Lima (UTC -5) timezone ends in UTC at 4:59 the next day.

If this same user creates an event that starts at midnight (and therefore tomorrow), the activity must not be displayed before midnight and therefore 5:00 the next day in UTC.

opw-3523558

Forward-Port-Of: odoo/odoo#144064
Forward-Port-Of: odoo/odoo#141949

\* = crm_livechat, im_livechat, test_mail, website_livechat The opportunity is taken to clean up and standardize headers/imports. - clean up obsolete # at the top of files - regroup imports from `odoo.tests` all together, apply import guidelines, remove unused imports - always have tagged usage with double quote, and in this order: test specific tags, post_install, -at_install Performance ----------- Post-install tests are parallelized on runbot, allowing to reduce build times. Before/after mail: 18.81s -> 0s test_mail: 113.7s -> 2.53s With this PR 130s can be gained on each runbot build with splits. Coverage -------- Post-install tests cover the full application (with all overrides installed) rather than a particular sub-set of the code. Tests of sub-set of the code are desirable too, but they are already tested with single-app builds on runbot. Maintenace ---------- Post-install tests are easier to maintain and to run, as dropping the database and installing it again is not necessary to run them.

The downpayment option on portal doesn't look like a switch. this commit transform the buttons into the default btn-group component to act like a regular switch. However since the page needs to refresh, we have to apply the classes manually with a switch triggering the checked attribute to obtain the expected visual result. task-3499055 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Steps to reproduce: ------------------- - be in UTC -5 (America/Lima for example) on the system (and so browser) and the user profile; - create an event from 4pm to 5pm the next day; - be at 2pm today; Issue: ------ We have a notification in activities for this event today, which is one day too soon. Cause: ------ To find the events that need to be notified to the user, we use a domain which, in this case, can be expressed as follows: ``` ( the `start` of the event must be after "now" (the event has not yet passed) OR the event `stop` must be after now (the event is in progress) ) AND the `start` of the event must be less than the end of the day (the event must be today) ``` The end of the day must be determined, but taking into account the user's timezone. As the domain has to work with UTC values (because the `start` and `stop` values of the event are in UTC in DB), in order to determine the end of the current day, we first need to determine which day the user is in UTC. Logic before this commit (using the example): ```py start_dt = datetime.datetime.utcnow() # 19:00 (because 14h in America/Lima -5) start_date = timezone(tz).localize(start_dt).astimezone(UTC).date() # 00:00 next day end_dt = datetime.datetime.combine(start_date, datetime.time.max) # 23:59 next day end_dt = timezone(tz).localize(end_dt).astimezone(UTC) # 4:59 second next day ``` The result (for an America/Lima timezone) is that if the event has its `start` in UTC before 4:59 two days later, the event will be notified. Solution: --------- Correct the values used to construct the domain. Logic after this commit (using the example): ```py start_dt_utc = now_utc.replace(tzinfo=UTC) # 19:00 (because 14h in America/Lima -5) start_dt = start_dt_utc.astimezone(user_tz) # 14:00 (because 14h in America/Lima -5) stop_dt = datetime.datetime.combine(start_dt.date(), datetime.time.max).replace(tzinfo=user_tz).astimezone(UTC) # 4:59 next day ``` Because 23:59 today using user timezone and then converted to UTC gives 4:59 next day. In fact, the day of a user in the America/Lima (UTC -5) timezone ends in UTC at 4:59 the next day. If this same user creates an event that starts at midnight (and therefore tomorrow), the activity must not be displayed before midnight and therefore 5:00 the next day in UTC. opw-3523558 Forward-Port-Of: odoo/odoo#144064 Forward-Port-Of: odoo/odoo#141949

This traceback arises when the user selects a product in website. To reproduce this issue: 1) Install `website_sale` 2) Open `website` and click on `shop` 3) Set `duration` and click on any product category `(eg: desk)` 4) A traceback appears Error: ``` UnboundLocalError: local variable 'all_tags' referenced before assignment File "odoo/http.py", line 2157, in __call__ response = request._serve_db() File "odoo/http.py", line 1732, in _serve_db return service_model.retrying(self._serve_ir_http, self.env) File "odoo/service/model.py", line 133, in retrying result = func() File "odoo/http.py", line 1759, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 1873, in dispatch return self.request.registry['ir.http']._dispatch(endpoint) File "addons/website/models/ir_http.py", line 235, in _dispatch response = super()._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 207, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 722, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/website_sale/controllers/main.py", line 481, in shop values.update({'all_tags': all_tags, 'tags': tags}) ``` On `shop` method `all_tags` was referenced before `assignment` form here https://github.com/odoo/odoo/blob/5ba7e9e16c45ba618bb728f336102454d844d144/addons/website_sale/controllers/main.py#L480-L481 sentry-4680583793 Forward-Port-Of: odoo/odoo#144297

Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be helpful in some cases, there should be a way to opt-out of the this automatic overwrite and to have a more flexible way to do those predictions. Here is how this is now possible: 1. With `disable_onchange_name_predictive` one can indicate their desire to opt-out of the prediction overwrite (i.e. the default behavior). 2. They can then use the `_predict_product`, `_predict_account`, `_predict_taxes` methods to create their own way of prediction. Placeholders for those were created to allow their use even if the prediction module isn't present. NB: As the module in charge of predictions (`account_accountant`) is not always installed the `edi_prediction_enabled` context key is used to indicate whether the prediction methods can be used or not. In the case of this fix, the key is setup in the `l10n_it_reports` module, as this module is always installed if `account_accountant` and `l10n_it` are installed. This way of predicting is useful for cases demanding a less generic approach to prediction. e.g. For the Italian EDI module the account of a line can be predicted without any limitation as it is not a value imported by the EDI. Whereas, its product and taxes should be predicted only if none were imported. opw-3201391 opw-3172035 Enterprise PR: https://github.com/odoo/enterprise/pull/51969 Forward-Port-Of: odoo/odoo#144437 Forward-Port-Of: odoo/odoo#115072

Odoo may allow prediction to occur when importing an EDI. i.e. predicting the product, account and taxes of each line. By default, those predictions will overwrite the actual value. Though it may be helpful in some cases, there should be a way to opt-out of the this automatic overwrite and to have a more flexible way to do those predictions. Here is how this is now possible: 1. With `disable_onchange_name_predictive` one can indicate their desire to opt-out of the prediction overwrite (i.e. the default behavior). 2. They can then use the `_predict_product`, `_predict_account`, `_predict_taxes` methods to create their own way of prediction. Placeholders for those were created to allow their use even if the prediction module isn't present. NB: As the module in charge of predictions (`account_accountant`) is not always installed the `edi_prediction_enabled` context key is used to indicate whether the prediction methods can be used or not. In the case of this fix, the key is setup in the `l10n_it_reports` module, as this module is always installed if `account_accountant` and `l10n_it` are installed. This way of predicting is useful for cases demanding a less generic approach to prediction. e.g. For the Italian EDI module the account of a line can be predicted without any limitation as it is not a value imported by the EDI. Whereas, its product and taxes should be predicted only if none were imported. opw-3201391 opw-3172035 Community PR: https://github.com/odoo/odoo/pull/144606 Forward-Port-Of: odoo/enterprise#51901 Forward-Port-Of: odoo/enterprise#38079

### Current behavior: The knowledge page's tree fails to load on the client's database, making the knowledge app unusable. ### Expected behavior: The tree loads correctly, allowing users to create and navigate knowledge articles. ### Steps to reproduce: - Create a large number of articles in the knowledge section. - Include multiple base64-encoded images in the body of these articles. - After some time, the tree fails to load, throwing a memory error. ### Reason for the problem: During tree construction, the ORM retrieves visible articles without pagination, which can create an excessive memory usage. The default prefetching loads all fields, including the body field, which can be large like in this case (1.2Gb). We can see that in memray, the cache is at 1.6Gb when the tree is fetched: ![2023-11-22_16-30](https://github.com/odoo/enterprise/assets/136497220/d96e8878-63a2-4d7f-82b7-0af4e2361631) ### Fix: Remove the prefetching of the body field in knowledge.article. This optimization speeds up the query and eliminates the possible memory error with a lot of large body. ### Reference: opw-3572719 Forward-Port-Of: odoo/enterprise#51786 Forward-Port-Of: odoo/enterprise#51340

Improvements(4)

[IMP] mail, *: move tests post install

[IMP] sale: suggest customer as follower

[IMP] sale: downpayment btn switch btn group

[IMP] website_sale_*: adapt to community changes

Refactoring(4)

[IMP] website_sale*: little improvements/cleanups

Other(50)

[FW][FIX] calendar: trigger activity according to timezone

Improvements(4)

[IMP] mail, *: move tests post install

[IMP] sale: suggest customer as follower

[IMP] sale: downpayment btn switch btn group

[IMP] website_sale_*: adapt to community changes

Refactoring(4)

[IMP] website_sale*: little improvements/cleanups

Other(50)

[FW][FIX] calendar: trigger activity according to timezone

[REF] mail: simplify discuss JS models

[MERGE][MOV] website_sale: split python files by classes

[REF] mail: simplify discuss JS models

[FW][FIX] web: avoid translation not ready error in errors

[FW][FIX] mrp: fix show mass produce backend/shopfloor

[FW][FIX] project,sale_timesheet: fix profitability section visibility

[FW][FIX] board: allow to save comparison

[FW][FIX] hr_recruitment: realign kanban footer items

[FW][FIX] iot: Build the url of iot_channel with dumps

[FW][FIX] product: prevent archived product variants from overshadowing active ones

[FW][FIX] web_editor: selection collapse on enter

[FW][FIX] account,hr_recruitment: disable OCR on demo documents

[FW][FIX] iot: change imports order in websocket_client

[FW][FIX] mail: avoid loading more messages than intended

[FW][FIX] sms: component getting destroyed

[FW][FIX] website_event_questions: copy template question translations

[FW][FIX] mail: traceback when switch nav list

[FW][FIX] website_sale: fix traceback when selecting a product in website

[FW][FIX] product: fixed wrong value for cost_currency_id

[FW][FIX] web: traceback in emoji picker

[FW][IMP] mail: validate discuss member fields when creating a channel

[FW][FIX] web: take arrow size into account when displaying popup

[FW][FIX] web_editor: ignore device visibility upon snippet drop

[FW][FIX] point_of_sale: maintain manual quantity for lot-tracked refunds

[FW][FIX] iot: Remove the useless function start_client

[FW][FIX] l10n_es_edi_tbai: fix discount computation traceback

[FW][FIX] l10n_it_edi: add flexible predictions

[FW][FIX] web_editor: traceback when changing color

[FW][CLA] Sign CLA

[FW][FIX] spreadsheet: Unable to copy text on safari

[FW][FIX] account_accountant: add flexible predictions

[FW][FIX] l10n_mx_edi: fix invoice pdf columns

[FW][FIX] appointment: display info page when having seconds in duration

[FW][FIX] l10n_es_reports: Fix Current Year / Past Year earnings

[FW][FIX] l10n_be_hr_payroll : Computation of remaining holiday pay for days

[FW][ADD] l10n_ar_edi: Allow the generation of negative lines for bonuses and advances on electronic invoices.

[FW][FIX] delivery_sendcloud: add params to logger

[FW][FIX] : iot: change local storage implementation

[FW][IMP] *_extract: set index content for expenses and resumes

[FW][FIX] account_invoice_extract: no auto extract on demo posted invoices

[FW][FIX] account_accountant: wait for reset in a bank reco tour step

[FW][FIX] l10n_pe_edi: always put invoice total in PayableAmount

[FW][FIX] hr_appraisal: make use of the right ribbon color

[FW][IMP] web_studio: add assertions in a test.

[FW][FIX] knowledge: Resolve memory error when loading knowledge tree

[FW][FIX] hr_appraisal: send appraisal request by email

[FW][FIX] account_accountant: wrong grouping in taxes with/out) deferred dates

[FW][FIX] web_grid: Allow use of magnifier glass while input is focused

[FW][FIX] web_map: prevent overlapping of menu dropdown in map view

[FW][FIX] account_report: handle anonymous partners asm.

[FW][FIX] l10n_de_reports: fix document field in datev export

[FW][FIX] website_appointment: fix blank invite if not part of multi-webs…