Odoo Changelog — 2022-12-21

Wednesday, December 21, 2022

37 changes · master

Improvements(5)

Enhancements to existing features

Master payment term big changes malb WIP

CoremasteraccountHigh impact

This work updates how payment terms are managed and applied in accounting documents, including invoices, discounts, configuration, and reports. It matters because payment schedules and early payment discounts affect customer billing, cash collection, and financial reporting accuracy.

Original PR description

WIP

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

#payment terms#invoicing#early payment discount#accounting

[IMP] {|website_}hr_recruitment: explicitate files purpose

PR #105935

Coremasterhr_recruitmentwebsite_hr_recruitment

The recruitment app's technical files have been reorganized into clearer, more focused sections. This does not change day-to-day hiring workflows, but it should make future updates easier and safer for the team maintaining the system.

Original PR description

Before this commit, recruitment models and views were mostly set inside 'hr_recruitment.py' and 'hr_recruitment_views.xml' respectively. In order to navigate easily, models are separated into distinctive files.

#recruitment#maintenance#organization

[IMP] payment_custom: allow for recomputing of pending message

PR #103903

Coremasterpayment_customMedium

Wire transfer payment instructions can now be refreshed after bank account details are added or changed. This helps businesses avoid showing incomplete payment messages to customers when bank information was not available during initial setup.

Original PR description

Before this commit (in the case the `custom_mode` is set to `wire_transfer`) the model tries to find existing bank accounts to compute a pending message with the necessary information. When bank accounts are not already setup we end with an incomplete message.

After this commit we can at any point recompute the pending message and it will be updated with the current bank information.

Task - 2511080


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

#payments#wire transfer#bank accounts

[IMP] project: improve recurrence notebook and project sharing

PR #105701

CoremasterprojectMedium

Project tasks are now ordered more usefully by priority and deadline, helping teams see urgent work sooner. Shared project pages also show the actual project name, and recurring task dates include the weekday for clearer scheduling.

Original PR description

Description of the feature this PR addresses:

- project sharing: display the name of the project in the action instead of 'project sharing'
- project.task: sort records by priority > deadline > sequence > id
- project.task form view > recurrence notebook: indicate the day of the week in the list of date

Task-3034635

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

#project#tasks#recurrence#sharing#sorting

[IMP] sale_subscription: add first contract date field

PR #34107

Enterprisemastersale_subscriptionMedium

Subscription contracts now include a dedicated first contract date, making it easier to see when a customer relationship originally began. This improves reporting on contract age without overloading existing order date fields that already have other meanings.

Original PR description

Before this commit, it was not possible to easily known when a contract first
started. Each renew has his own start_date but it is important to see easily
how old is a contract in reports.

There are several date fields on the sale order and we decided to create a new one
instead of reusing date_order. date_order has already two meaning depending on the
state of the order: create_date for quotations and order_date for confirmed orders.
We think that giving a third meaning to the same field would be confusing.

taskid: 3071690

#subscriptions#contracts#reporting

Bug Fixes(1)

Resolved issues and error corrections

[FIX] payment term WIP

PR #35033

Enterprisemasteraccount_accountantl10n_mx_edi_40Medium

This update corrects a work-in-progress issue affecting payment terms in accounting workflows. It helps ensure accounting reconciliation and related localization tests behave more reliably, reducing the risk of payment term errors in day-to-day finance operations.

Original PR description

WIP

#payment terms#accounting#reconciliation

Other(31)

Miscellaneous changes

[FW][FIX] sale_management: do not recompute quote template on company change

PR #108380

Coremastersale_management

--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#108333 Forward-Port-Of: odoo/odoo#107734

Original PR description

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

Forward-Port-Of: odoo/odoo#108333
Forward-Port-Of: odoo/odoo#107734

[FW][FIX] web: incorrect CSS selector

PR #108371

Before this commit, recruitment models and views were mostly set inside 'hr_recruitment.py' and 'hr_recruitment_views.xml' respectively. In order to navigate easily, models are separated into distinctive files.

Before this commit (in the case the `custom_mode` is set to `wire_transfer`) the model tries to find existing bank accounts to compute a pending message with the necessary information. When bank accounts are not already setup we end with an incomplete message. After this commit we can at any point recompute the pending message and it will be updated with the current bank information. Task - 2511080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Description of the feature this PR addresses: - project sharing: display the name of the project in the action instead of 'project sharing' - project.task: sort records by priority > deadline > sequence > id - project.task form view > recurrence notebook: indicate the day of the week in the list of date Task-3034635 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, it was not possible to easily known when a contract first started. Each renew has his own start_date but it is important to see easily how old is a contract in reports. There are several date fields on the sale order and we decided to create a new one instead of reusing date_order. date_order has already two meaning depending on the state of the order: create_date for quotations and order_date for confirmed orders. We think that giving a third meaning to the same field would be confusing. taskid: 3071690

When checking if a line in traceability report is unfoldable, `_get_move_lines` is a costly operation and should be executed last when all other conditions are satisfied. Without this change, when opening Traceability report for a LOT used in around 1.3k orders, it takes roughly more than 2mins to render. ```python3 1 0 0.01 @profile def _lines(self, line_id=None, model_id=False, model=False, level=0, move_lines=[], **kw): 1 0 0.0 final_vals = [] 1 0 0.01 lines = move_lines or [] 1 0 0.0 if model and line_id: move_line = self.env[model].browse(model_id) move_lines, is_used = self._get_linked_move_lines(move_line) if move_lines: lines = move_lines else: # Traceability in case of consumed in. lines = self._get_move_lines(move_line, line_id=line_id) 1385 0 11.19 for line in lines: 1383 0 3.59 unfoldable = False 1383 14495 162562.31 if line.consume_line_ids or ( line.lot_id and self._get_move_lines(line) and model != "stock.production.lot"): 1 0 0.0 unfoldable = True 1383 23 1607.97 final_vals += self._make_dict_move(level, parent_id=line_id, move_line=line, unfoldable=unfoldable) 1 0 0.0 return final_vals Total: 1 14518 164185.09 ``` With this change, as we check other conditions first before checking with `_get_move_lines`, the performance is improve significantly (render in seconds) ```python3 1 0 0.01 @profile def _lines(self, line_id=None, model_id=False, model=False, level=0, move_lines=[], **kw): 1 0 0.0 final_vals = [] 1 0 0.03 lines = move_lines or [] 1 0 0.0 if model and line_id: move_line = self.env[model].browse(model_id] move_lines, is_used = self._get_linked_move_lines(move_line) if move_lines: lines = move_lines else: # Traceability in case of consumed in. lines = self._get_move_lines(move_line, line_id=line_id) 1385 0 8.79 for line in lines: 1383 0 3.35 unfoldable = False 1383 4 230.8 if line.consume_line_ids or (model != "stock.production.lot" and line.lot_id and self._get_move_lines(line)): 1 0 0.0 unfoldable = True 1383 31 1433.17 final_vals += self._make_dict_move(level, parent_id=line_id, move_line=line, unfoldable=unfoldable) 1 0 0.0 return final_vals Total: 1 35 1676.15 ``` --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#107884 Forward-Port-Of: odoo/odoo#107677

To reproduce the issue: - Go to website > Add language > Add blocks to your homepage and translate it. - Make translations on the "Contact us" page (or a new custom page). - Install a new app > The translation of the homepage is lost (only on homepage). Explanation: After [1], The `_load_module_terms()` method was updated on website module to copy translations from base to specific views when module translation is loaded. And since [2], the translated field's column is either NULL or a JSON dict mapping language codes to text (the field's value in the corresponding language). To explain what happens exactly when new app is installed, let's suppose we want to load module translation for the config {'en_US', 'fr_BE'} in the following situations: S1 (e.g. "Contact us" page): -=-=-=-=-=-=--=-=-=-=-=-=-=-= ``` generic_arch_db = { 'en_US': '<div>Generic (EN)</div>', 'fr_BE': '<div>Generic (FR)</div>' } specific_arch_db = { 'en_US': '<div>Specific (EN)</div>', 'fr_BE': '<div>Specific (FR)</div>' } ``` `_load_module_terms()` will copy translations for 'fr_BE' from generic to specific `arch_db` (using generic translation dictionary). result: ``` new_specific_arch_db = { 'en_US': '<div>Specific (EN)</div>', 'fr_BE': '<div>Updated Specific (FR)</div>' } ``` S2 (new custom page): -=-=-=-=-=-=--=-=-=-=-=- ``` generic_arch_db = NULL specific_arch_db = { 'en_US': '<div>Specific (EN)</div>', 'fr_BE': '<div>Specific (FR)</div>' } ``` result: Nothing to do here (only specific version), the specific translation will not be updated. S3 (e.g. website homepage): -=-=-=-=-=-=--=-=-=-=-=-=-=-=- The generic view has no translated `arch_db` (only the 'en_US' version): ``` generic_arch_db = {'en_US': '<div>Generic (EN)</div>'} specific_arch_db = { 'en_US': '<div>Specific (EN)</div>', 'fr_BE': '<div>Specific (FR)</div>' } ``` `_load_module_terms()` will copy generic translations only for languages available on "generic_arch_db" and the 'fr_BE' version will be lost. result: `new_specific_arch_db = {'en_US': '<div>Specific (EN)</div>'}` The goal of this commit is to prevent this behaviour by keeping the specific translated `arch_db` even when the generic value has no content for the translation language. Remark: This behaviour occurred while loading module translations, as a consequence, the specific translations are also lost when the website module is updated. [1]: https://github.com/odoo/odoo/commit/94db81d8d28c4cbc7b51ae1688c9362042ee3619 [2]: https://github.com/odoo/odoo/commit/ef00294e7189359c47638c4a71626f1937395edb opw-3083480 Forward-Port-Of: odoo/odoo#107822

Because of the multi-company record rule on data_merge_record, each search on `env['data_merge.record']` (without sudo) will call `_search_company_id`. That's because data_merge.record.company_id is a non-stored computed field. This method fetches all records (`active_test=False`) on the data_merge_record table then calls filtered on the resulting recordset. This induces two performance bottlenecks. One, a filtered on a potentially huge amount of records (data_merge_record can grow quite big) can lead to slowdowns. Two, since company_id is a computed field, accessing this field inside the filtered lambda function means to recompute the field value. So, if we are filtering 300K records on company_id, the corresponding compute function will be called 300 times. Optimizing that in stable is not really straightforward, as the easiest solution (done in master odoo/enterprise#33768) would be to store the company_id field. Here we avoid calling the compute function of company_id and instead we "manually" build a subquery by combining custom SQL and Query objects constructed with the _search method. Injecting the resulting Query in a domain of the form `[('id', 'in', Query)]` leads to significant speedups in large databases. #### speedup N.B: This benchmark was done before the merge of odoo/enterprise#33678. The benchmark being a bit long to carry out, I left the old version here. From a few tests that I made, the post-merged version performs the same or worse than the pre-merged one used for benchmarking. The Before PR/After PR speedup gains should therefore be the same or better than what's written hereunder. Because of the way the subquery is generated, the overall performances depends on the number of records, the number of distinct res_model_names and the number of res_model with a company_id field. ##### Number of records Customer database with 348 513 data_merge_records, 8 distinct res_model_names, 5 res_model_names w/o company_id field, 3 res_model_names w company_id field. Opening Data Cleaning App: search_panel_select_range/web_read_group timing | Number of records | Before PR | After PR | |:------------------------:|:---------------:|:--------------:| |10 000 | 1.8s/3s | 125ms/1.8s | |25 000 | 7s/10s | 125ms/2s | |50 000 | 10s/20s | 400ms/6s | |100 000 | 30s/1m | 500ms/7.5s | |200 000 | 1m25/2m48 | 600ms/12s | |348 513 | 3m40/7m30 | 1.8s/16s | For the next two sections, only the After PR timings are shown. This is to showcase the impact of the number of res_model with/without company on the request timings. The Before PR execution time is the same as above for 200 000 records. ##### Number of res_models without company_id Testing database with 200 000 data_merge_records, 8 distinct res_model_names, 4 res_model_names w/o company_id field, 4 res_model_names w company_id field. The number of data_merge_records is kept constant (160 000 w company field records + uniform distribution for the remaining 40 000 records without company_id). |Number of model w/o company | After PR | |:-----------------------------------------:|:-------------:| |1 | 400ms/4.5s | |2 | 400ms/4.7s | |3 | 400ms/5.2s | |4 | 400ms/5.6s | ##### Number of res_models with company_id The number of data_merge_records is kept constant (160 000 without company field records + uniform distribution for the remaining 40 000 records with company_id). |Number of model w company | After PR | |:--------------------------------------:|:--------------:| |1 | 200ms/2.5s | |2 | 280ms/3.2s | |3 | 325ms/4.1s | |4 | 350ms/5.25s | opw-2968536 Forward-Port-Of: odoo/enterprise#35145 Forward-Port-Of: odoo/enterprise#33773

**Steps to reproduce the bug:** - Enable “Workorders” in the mrp settings - Create a storable product “P1”: - tracked: by serial number - BoM: - Operation: - OP1 - Components: - C1: tracked by serial number and consumed in “OP1” - C2: tracked by serial number and consumed in “OP1” - update the quantity of C1 and C2 with 3 serial number “SN1”, “SN2”, “SN2” - Create a MO to produce 3 unit of “P1” - Start the workorder - the Serial number “SN1” is automatlicaly set - finish the first production, validate and record the production - The MO gets split (Backorder) and the next one is started - The Component consumption step proposes (prefills the SN field with the last one “SN3” instead of “SN2” - Finish the second production and start the last one - the “SN3” is prefilled a 2nd time while it has already been used **Problem:** When the backorder is created and confirmed, the workorder is also confirmed: https://github.com/odoo/odoo/blob/7632110aa87da2a84e33506174f6dbb34284da6a/addons/mrp/models/mrp_production.py#L1212 A quality check is then created with the correct SN: https://github.com/odoo/enterprise/blob/b85075efb624deaa3e9ea14cb94bc8a675ce3965/mrp_workorder/models/mrp_workorder.py#L725 https://github.com/odoo/enterprise/blob/15.0/mrp_workorder/models/mrp_workorder.py#L439 But another `qualit.check` with the latest Serial number “SN3” is set as `current_quality_check_id` which is wrong https://github.com/odoo/enterprise/blob/76817ab5f4a5c40e9a7fc05c8dc3e2b775d7e81a/mrp_workorder/models/mrp_workorder.py#L514 opw-2976491 Forward-Port-Of: odoo/enterprise#34854 Forward-Port-Of: odoo/enterprise#34475

Improvements(5)

Master payment term big changes malb WIP

[IMP] {|website_}hr_recruitment: explicitate files purpose

[IMP] payment_custom: allow for recomputing of pending message

[IMP] project: improve recurrence notebook and project sharing

[IMP] sale_subscription: add first contract date field

Bug Fixes(1)

[FIX] payment term WIP

Other(31)

[FW][FIX] sale_management: do not recompute quote template on company change

[FW][FIX] web: incorrect CSS selector

Improvements(5)

Master payment term big changes malb WIP

[IMP] {|website_}hr_recruitment: explicitate files purpose

[IMP] payment_custom: allow for recomputing of pending message

[IMP] project: improve recurrence notebook and project sharing

[IMP] sale_subscription: add first contract date field

Bug Fixes(1)

[FIX] payment term WIP

Other(31)

[FW][FIX] sale_management: do not recompute quote template on company change

[FW][FIX] web: incorrect CSS selector

[FW][FIX] web: remove incorrect usage of patch in mock_env

[FW][FIX] website: allow step to fill more than 9/12 of the page width

[FW][FIX] tools/transpiler: avoid nested quantifiers

[FW][FIX] mass_mailing, web_editor: properly handle custom/non-custom button styles

[FW][FIX] sms: improper reload of form view after sms wizard on new record

[FW][FIX] website: fix table of content scrollSpy offset

[FW][FIX] payment: user is able to delete linked journals

[FW][FIX] web: status_indicator: 'unable to save' not aligned

[FW][FIX] theme_kea: fix faulty shape on s_picture

[FW] 16.0 e-commerce : hide price list when only one available

[FW][FIX] web_editor: spacing when changing format in checklists

[FW][IMP] stock: improve traceability report perf

[FW][FIX] pos_coupon: correctly filter out global discount

[FW][FIX] stock: delivery address for entire packages

[FW][IMP] l10n_lu: adapt tax report to 2023 updates

[FW][FIX] website: fix homepage translation overwriting

[FW][FIX] sale_timesheet: fix project_update description

[FW][FIX] project,note,hr_timesheet: fix the various ui issue

[FW][FIX] sale: disable confirmation warning after cancellation on portal

[FW][FIX] data_merge: speed up _search_company_id on big databases.

[FW][FIX] sale_timesheet_enterprise: fix remaning hours warning

[FW][FIX] spreadsheet_edition: drop group in search bar

[FW][IMP] l10n_lu_reports_electronic{_xml_2_0}: adapt tax report to 2023

[FW][FIX] hr_payroll: alert-warning overlapping with field

[FW][FIX] hr_payroll: remove the unnecessary scroll in Salary Rules

[FW][FIX] social_instagram: error when posting images

[FW][FIX] web_enterprise: fix non deterministic webclient tests

[FW][FIX] mrp_workorder: set the correct SN in the component consumption

[FW][FIX] hr_appraisal: smart button showing proper date for different timezones