Odoo Changelog — 2024-01-31

Wednesday, January 31, 2024

51 changes · saas-17.1

Bug Fixes(3)

Resolved issues and error corrections

[FIX] website: properly clean the form after editing the send action

Coresaas-17.1website

Fixed an issue where website form fields could remain visibly editable after changing the form's send settings and saving. This helps ensure saved website pages appear correctly to visitors and avoids confusing editor artifacts.

Original PR description

With commit [1], the ability to add property field inside a website form was implemented. In this case, some models have different fields available depending on the action they perform. E.g. if you select "Create a task", depending on which project you choose to create a task in, different fields will be available.

For that reason, the decision was made to destroy the SnippetEditors of existing fields, so that they would update their available fields.

However, while we destroy the editors, we do not properly clean the DOM before destroying them. This can lead to editor elements still being in the DOM after saving.

Steps to reproduce:
- Drop a form snippet
- Add a "selection" field
- Change the email address on which the form will be sent to
- Click on save => The selection field is still in editable mode

This commit fixes that by properly calling `cleanForSave` before destroying the SnippetEditors.

[1]: https://github.com/odoo/odoo/commit/5c08ac23

Related to task-3278975

#website#forms#editor#save

[FIX] web: adapt forgotten use of services.rpc

PR #151788

Coresaas-17.1web

This update restores two user navigation actions that could fail after an internal service change. Users can reliably open “My Account” from the user menu and trigger the home action without interruption.

Original PR description

Since [1], the rpc service no longer exists, and the rpc function can be directly imported. This PR adapts a forgotten usecase, accessible when clicking on "My account" in the user menu.

[1] odoo/odoo@137c43d02a27aec8302f823d8e3a1f18599489a2

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

#user menu#my account#navigation

[FIX] mrp_workorder: invalid props

PR #55169

Enterprisesaas-17.1mrp_workorder

This update fixes an issue in Manufacturing shop floor quality check dialogs caused by a recent technical change in how selection fields receive their settings. It helps prevent errors when users interact with related record fields during work order quality checks.

Original PR description

Due to commit [1]

The props on context for m2o take an object but the shopfloor hasn't been adapted

[1] https://github.com/odoo/odoo/commit/3670f78be767396f322ff3ebf068af5c2f547b36

#manufacturing#shop floor#quality checks

Other(48)

Miscellaneous changes

[FW][FIX] mrp: Manufacturing Forecast access from template

PR #152100

Coresaas-17.1mrp

Have a product template with bom Ensure the product variant has not the same id of the template (Add and remove a template variant) In the product page > Hit "forecasted" smart button > "Manufacturing Forecast" Error will raise: Missing record Record does not exist or has been deleted. This occurs because when opening the Manufacturing Forecast from the template product we are searching the variant using the id of the template product opw-3636661 Forward-Port-Of: odoo/odoo#151

Original PR description

Have a product template with bom
Ensure the product variant has not the same id of the template
(Add and remove a template variant)
In the product page > Hit "forecasted" smart button > "Manufacturing Forecast"

Error will raise:
Missing record
Record does not exist or has been deleted.

This occurs because when opening the Manufacturing Forecast 
from the template product we are searching the variant using the 
id of the template product

opw-3636661

Forward-Port-Of: odoo/odoo#151776
Forward-Port-Of: odoo/odoo#149736

With commit [1], the ability to add property field inside a website form was implemented. In this case, some models have different fields available depending on the action they perform. E.g. if you select "Create a task", depending on which project you choose to create a task in, different fields will be available. For that reason, the decision was made to destroy the SnippetEditors of existing fields, so that they would update their available fields. However, while we destroy the editors, we do not properly clean the DOM before destroying them. This can lead to editor elements still being in the DOM after saving. Steps to reproduce: - Drop a form snippet - Add a "selection" field - Change the email address on which the form will be sent to - Click on save => The selection field is still in editable mode This commit fixes that by properly calling `cleanForSave` before destroying the SnippetEditors. [1]: https://github.com/odoo/odoo/commit/5c08ac23 Related to task-3278975

Since [1], the rpc service no longer exists, and the rpc function can be directly imported. This PR adapts a forgotten usecase, accessible when clicking on "My account" in the user menu. [1] odoo/odoo@137c43d02a27aec8302f823d8e3a1f18599489a2 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

To reproduce: - Log-in as admin - Switch to debug mode - Go to Events / Configuration / Event Templates - Create a new template: * Name: Online Conference - Check 'Website menu', 'Community' and 'Allow Room Creation' option, - Save it - Go to Events / Events - Create a new event: * Name: New Online Conference * Template: Online Conference - Save it and click on 'Go to Website' smartbutton - Then click on 'Community' submenu - In the right panel, click on "Create a Room" It crashes with: ``` TypeError: ctx.widget is undefined template@.../web/assets/1/debug/web.assets_frontend_lazy.js line 13622 > Function:26:29 (/web/static/lib/owl/owl.js:5532) render@.../web/assets/1/debug/web.assets_frontend_lazy.js:66320:28 (/web/static/src/core/utils/render.js:56) renderToElement@.../web/assets/1/debug/web.assets_frontend_lazy.js:66272:22 (/web/static/src/core/utils/render.js:8) _onClickCreate@.../web/assets/1/debug/web.assets_frontend_lazy.js:132115:35 (/website_event_meet/static/src/js/website_event_create_meeting_room_button.js:25) ``` This revert odoo/odoo@065a2f451a88 change for `website_event_meet`, as in that case the `csrf_token` value is provided directly as context value to `renderToElement` (see `websiteEventCreateMeetingRoom` publicwidget `_onClickCreate` handler) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#151761

This PR fixes an issue related to the colorpicker component, presents in both back-end and front-end. They use the same XML template but they have two different selectors within our SCSS files. task-3693078 ------------------ Some months ago, commit[1] removed some `@extend` rules related to button design within the `web_editor`, and replaced them with a `.btn` BS class. This affected both colorpicker since they share a common template, and causes layout issues on the "front-end web editor", which was not the expected output. The issue was fixed directly with commit[2], but by removing the `.btn` class from the template, it removed the whole styling on the back-end color picker, making it use the user agent button styling. == After == Since the colorpicker already has some CSS variables to handle its design depending on the context, we make use of the CSS variables to customize the design of the component when it is inside the backend, and make it look as it was before it lost its `.btn` class. | 17.0 | 17.0-fix-colorpicker-button-issue-chgo | | ------------- | ------------- | | ![image](https://github.com/odoo/odoo/assets/128030743/6a147c84-fec1-4cf8-8f85-42982b9dab71) | ![image](https://github.com/odoo/odoo/assets/128030743/b8f1e186-c610-4ee5-b371-86d2cfb52ab6) | Commit[1]: ee38c69503a0fd9175751f054d88bf760ec660b8 Commit[2]: 711fc86368eb5283cb0962620f0557d381904fde Forward-Port-Of: odoo/odoo#150157

When a user only has access to a branch of a company, there is a lot of places where AccessError pops up because of how the domain was previously set on them. This commit aims to be a part of frequent small PR in the future to fix these problems. These PRs fixes: - Unaccessible parent company's fields (now accessible) in - Sales/Purchase Orders/Quotation form: product variant, product (product_template), and tax - Account Move (invoice/bill/etc) line, when filling product - Access Error as user with only access to branch when: - opening Accounting reports (BS / PL) - opening PoS dashboard - trying to add product when creating new invoice - Improves Journal access rules. Instead of making all parent's journal public, base the user access on: (explicitly granted access from user allowed companies) or (all self&parent's journal AND journal type is not Bank/Cash) - Improves styling on report's Journal dropdown button's style (in enterprise PR) community-PR: https://github.com/odoo/odoo/pull/140078 enterprise-PR: https://github.com/odoo/enterprise/pull/49820 [task-id: 3551305](https://www.odoo.com/web?debug=#id=3551305&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/odoo#151562 Forward-Port-Of: odoo/odoo#140078

When we update an inline translated element (like ``) for the base language `en_US` we should update the modifiers attributes for all languages. For example when updating from (16.0) https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/views/ir_ui_view_views.xml#L127-L129 https://github.com/odoo/odoo/blob/7ecd9413/odoo/addons/base/i18n/fr.po#L7233-L7235 to (17.0) https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/views/ir_ui_view_views.xml#L126-L128 https://github.com/odoo/odoo/blob/b1461d28/odoo/addons/base/i18n/fr.po#L12087-L12089 The base term, `en_US`, is updated since the text matches but the attributes of the translated terms, `fr_FR` for example, are not updated. Later when the PO file is loaded in non-overwrite mode the translated terms for `fr_FR` is not updated. This causes all sort of issues during an upgrade for inline-translated terms -- like ``. More so since the recent change that converts domain-based attributes into inline Python expressions. In this patch we propagate modifiers attributes from inline-translated items in the new base term into all translated terms when the base term is updated. In that way we ensure the attributes are correct in all languages even if later the loading of their corresponding PO file doesn't update the term. For a detailed example, let's see what happens when loading the view above during an upgrade 16->17, right at the first load of the XML file at https://github.com/odoo/odoo/blob/b1461d28/odoo/fields.py#L1864 ``` (Pdb) p old_term 'This view has no previous version.\n This view is not coming from a file.\n You need two views to compare.' (Pdb) p closest_term 'This view has no previous version.\n This view is not coming from a file.\n You need two views to compare.' (Pdb) p translation_dictionary[old_term] defaultdict(<class 'dict'>, {'fr_FR': 'Cette vue n\'a pas de version antérieure.\n Cette vue ne provient pas d\'un fichier.\n Vous avez besoin de deux vues pour comparer.'}) ``` As we can see the new term will get an updated value for its `invisible` attribute, while also removing `attrs`. The translated terms will be still keep the old modifier though. Now later when the fr_FR.po file is loaded we reach this point https://github.com/odoo/odoo/blob/b1461d28/odoo/tools/translate.py#L1442 ``` (Pdb) p term_en 'This view has no previous version.\n This view is not coming from a file.\n You need two views to compare.' (Pdb) p translation_dictionary[term_en] defaultdict(<function DeepDefaultDict at 0x7fc9640cdfc0>, {'fr_FR': 'Cette vue n\'a pas de version antérieure.\n Cette vue ne provient pas d\'un fichier.\n Vous avez besoin de deux vues pour comparer.'}) ``` Thus the translated values are NOT updated, keeping the _wrong_ modifiers. This is later fixed during the upgrade in a clumsy way. C.f. the warnings like this one in runbot: ``` Incomplete conversion for view(id=77, lang=fr_FR) at Cette vue n'a pas de version ant&https://github.com/odoo-dev/odoo/pull/233;rieure. ``` Note that such warnings are gone in current PR CI. The root issue here is that when the fr_FR translation is loaded the terms are not updated due to a combination of factors: 1. The text content of the term didn't change 2. There is no override flag set for translations Option 2 is not a valid option during upgrades because we want to keep custom translations. We could instead of the current patch tweak how option 1 works and perhaps make the closest term more restricted. This would lead to the update of the whole translation though while the actual issue here is _just_ the modifiers. Moreover if the translations are out of sync the translated terms will still keep the wrong values that could still be essential for the correct functioning of the record they belong too (view archs -- for example). Finally this is a more extreme case (16.0): https://github.com/odoo/enterprise/blob/1e63b4a8/sale_subscription/views/sale_order_views.xml#L142 In this case during the upgrade we fix the modifier value (refer to runbot warning above -- it's the same script that fixes it) and set ``` invisible="(subscription_management == 'upsell') or (recurrence_id == False)" ``` for translations, which is wrong. The correct value is (17.0): ``` invisible="not plan_id or subscription_state == '7_upsell'" ``` https://github.com/odoo/enterprise/blob/530ba3ad/sale_subscription/views/sale_order_views.xml#L136 Forward-Port-Of: odoo/odoo#150152

Before this commit, in the command palette, during a search, it is possible that the value entered is modified. The problem only occurs if the namespace has a debounceDelay bigger than 0 and at least one of its command providers is async. How to reproduce: ================= - Go to the command palette with the @ namespace. - Type a few characters - Re-enter a few characters If you repeat this operation several times, some characters may disappear. Why: ==== The value of the input is modified at each "input" event, but the searchValue in the state is only modified when the debounce trigger "search". Since the command palette template is contained in a slot, each state change causes a complete rendering of the command palette. When the search is executed, the commands are added to the state after each provider has generated them, so a rendering takes place and it is the value contained in state.searchValue that is used for the input and not the value contained in it before the rendering. Solution: ========= No longer modify state.searchValue during the search, but at each input event. 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#151772

Steps: - Create a draft mailing based on a theme that has the snippets menu (the "Event Promo" theme, for instance). - Create another draft mailing, this time based on the basic theme ("Plain Text"). - Switch from the former to the latter using the form view pager. The editor for the basic theme record is not supposed to have a sidebar (snippets menu), as it uses the floating toolbar instead. But when switching between records like described above, the basic theme gets replaced by the theme of the preceding record, and the snippets menu is added to the UI. This happens because [1] patched the `setValue` function to handle the case where the element for dropping snippets (.o_mail_wrapper_td) is missing, in particular if it gets removed via the codeview. Such fix most likely had in mind the scenario where the codeview is toggled on and off, but not the call to `setValue` that also happens when switching between records via the form view pager. As a result, the html content of a record based on the basic theme, in which such "dropzone" is absent, is added as a child of the previous record's .o_mail_wrapper_td element. This is certainly not the desired behavior, as it ends up overwriting the basic theme by the one from the previous record (the theme is defined by a class in the .o_layout div, which is a parent of the .o_mail_wrapper_td element). This commit, besides fixing the described issue, takes the opportunity to add a comment with the presumed reasoning behind commit [1] and extends the test tour in order to prevent regressions. [1]: https://github.com/odoo/odoo/commit/9be2cb538f937645be4650af1031c8a1445bb48b task-3573951 Forward-Port-Of: odoo/odoo#148718 Forward-Port-Of: odoo/odoo#140197

**Current behavior:** Trying to post journal entries for an expense report sheet containing an expense that has: A) an associated analytic distribution with both a Project and Department, and B) a customer to be re-invoiced (requires the expense to be for a product which permits this operation), attempting to post the journal entries for the approved expense sheet will raise a ValueError. --- **Expected behavior:** The entries get posted to their respective accounting journals. --- Steps to reproduce: 0. Install the Project, Accounting, Sales, Expense apps and enable analytic accounting in the db settings 1. Create a new expense with: A) an analytic distribution which has both available fields filled out, and B) a category that permits a customer to be re-invoiced (then enter a customer) 2. Create the report, submit it to the manager, approve it, then attempt to post the journal entries 3. This should cause the traceback, if the process was blocked try again after deleting any tax rules in the expense --- Cause of the issue: The analytic_distribution field in the hr.expense module is stored as a dictionary. During the process of recording the journal entries, the keys are converted from a string to integers. However, when multiple keys are in the dict, the conversion is set up improperly and fails. --- Fix: Modify the conversion sequence so that multiple dict keys are accounted for. --- opw-3663082 Forward-Port-Of: odoo/odoo#147985

[FIX] mrp: Fail to set workorder on calendar 'Planning by Workcenter' **Steps to reproduce:** 1- Install Manufacturing module 2- Create 2 or more new WOs and make sure that their corresponding MOs is not planned 3- Go to Operations > Work orders 4- Mark all of those WOs and write a start date to apply on all of them 5- Check Planning > Planning by Workcenter 'you will not find the scheduled WOs' **Current behavior before PR:** When you try to mark more than one record in Work orders and set start date for all of them at the same time it will not be set therefore it will not be visible in Planning calendar. This is happening because if you are setting the start date for the first time it will call the function that sets the start date first before calculating the finish date so it will not pass the condition where it checks if both dates have values. **Desired behavior after PR is merged:** Now we are checking just the start date if it has value or not and to raise the same user error if the customer tries to delete the finish date we are checking this on change of the finish date from a value to null. opw-3596100 Forward-Port-Of: odoo/odoo#151272 Forward-Port-Of: odoo/odoo#147861

[FIX] website: destroy widgets before instantiating the wysiwyg Steps to reproduce the problem: - Add a "Countdown" snippet on the website. - Save. - Enter in edit mode again. -> Problem: the `destroy()` of the `CountdownWidget` public widget comes from a `widgets_start_request` that is triggered when the `WysiwygAdapterComponent` has been mounted and patched (see [useEffect documentation]). The problem is that, as the widgets are only destroyed at this moment, it is possible that a widget could replace an element that has been modified during the instantiation of the `WysiwygAdapterComponent`. For example: - At the `onWillStart()` hook of the `WysiwygAdapterComponent`, the `o_editable` is added on some elements. - A widget could then replace one of these elements. - The widget is destroyed after the rendering of the `WysiwygAdapterComponent`. -> The `o_editable` class is not on the element anymore. The goal of this commit is to, as before [1], destroy the existing widgets before instantiating the `wysiwyg`. This commit also adds a test to ensure that the order of the calls to the widgets and wysiwyg lifecycle methods is coherent. Related to runbot-28700 [1]: https://github.com/odoo/odoo/commit/a3e34512bf229d5d55f9e9d9eb0a9f7211a5a826 [useEffect documentation]: https://github.com/odoo/owl/blob/master/doc/reference/hooks.md#useeffect Forward-Port-Of: odoo/odoo#151411 Forward-Port-Of: odoo/odoo#149385

When a user only has access to a branch of a company, there is a lot of places where AccessError pops up because of how the domain was previously set on them. This commit aims to be a part of frequent small PR in the future to fix these problems. This also includes small style improvement for report's dropdown button for Journal filter, to make it clear that company name is not clickable These PRs fixes: - Unaccessible parent company's fields (now accessible) in - Sales/Purchase Orders/Quotation form: product variant, product (product_template), and tax - Account Move (invoice/bill/etc) line, when filling product - Access Error as user with only access to branch when: - opening Accounting reports (BS / PL) - opening PoS dashboard - trying to add product when creating new invoice - Improves Journal access rules. Instead of making all parent's journal public, base the user access on: (explicitly granted access from user allowed companies) or (all self&parent's journal AND journal type is not Bank/Cash) - Improves styling on report's Journal dropdown button's style (in enterprise PR) community-PR: https://github.com/odoo/odoo/pull/140078 enterprise-PR: https://github.com/odoo/enterprise/pull/49820 [task-id: 3551305](https://www.odoo.com/web#id=3551305&cids=1&menu_id=4720&action=333&active_id=967&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#55345 Forward-Port-Of: odoo/enterprise#49820

Bug Fixes(3)

[FIX] website: properly clean the form after editing the send action

[FIX] web: adapt forgotten use of services.rpc

[FIX] mrp_workorder: invalid props

Other(48)

[FW][FIX] mrp: Manufacturing Forecast access from template

Bug Fixes(3)

[FIX] website: properly clean the form after editing the send action

[FIX] web: adapt forgotten use of services.rpc

[FIX] mrp_workorder: invalid props

Other(48)

[FW][FIX] mrp: Manufacturing Forecast access from template

[FW][FIX] hr_expense: Fix product cost digits

[FW][FIX] website_event_meet: fix crash when creating event meeting room

[FW][FIX] web_editor: fix colorpicker buttons design

[FW][FIX] web: open record from list with a x2m field on virtual record

[FW][FIX] mass_mailing: multiple attachments for same image

[FW][FIX] pos_mrp: handle multiple order lines with kits

[FW][FIX] spreadsheet: keep leading zeros of char fields

[FW][FIX] pos_loyalty: fix test

[FW][FIX] account: Send & Print link invoice if after service fails

[FW][IMP] stock: allow to filter orderpoint locations

[FW][FIX] point_of_sale: fix report total paid amount

[FW][FIX] analytic: populate analytic lines

[FW][FIX] website, *: make custom search model work when no website_id

[FW][FIX] account,sale,pos,*: branch user access

[FW][FIX] core: propagate update of modifiers attributes from base terms

[FW][FIX] web: CP keep the correct searchValue

[FW][FIX] point_of_sale: sync orders on pos closing

[FW][FIX] mass_mailing: switch to basic theme record

[FW][FIX] website_livechat: fix message reaction tour

[FW][FIX] hr_holidays: Fix accrual plan read access

[FW][FIX] calendar: fixes traceback when end is not set

[FW][FIX] account: dashboard separate invoices / bills to validate links

[FW][15.0][IMP] stock: Avoid unneeded write in _enable_show_reserved method

[FW][FIX] web_editor: fix CTA button for upgrades

[FW][FIX] point_of_sale: add missing indexes for create_from_ui

[FW][FIX] hr_timesheet: fix space between avatar and employee name

[FW][FIX] sale{,_expense}: bad conversion distr. keys

[FW][FIX] mail: set body on mail.message on event registration confirmation

[FW][FIX] website_sale: hide header from user that shouldn't see an alert

[FW][FIX] web_editor: fix rollback on pasting using ctrl+shift+v

[FW][FIX] l10n_fr: fix "Domestique - France" fiscal position

[FW][FIX] payment_xendit: neutralize

[FW][FIX] website_[membership,partner,customer]: redirect to real slug

[FW][FIX] project_timesheet_holidays: Fix company right issues

[FW][FIX] mrp: Fail to set workorder on calendar 'Planning by Workcenter'

[FW][FIX] website_slides: fix channel progress bar / completed tag width

[FW] Destroy existing widgets before instantiating the wysiwyg

[FW][FIX] l10n_dk_edi: Renaming of the module

[FW][FIX] frontdesk: fix tour

[FW][FIX] l10n_fr_reports: unlink record if exists

[FW][FIX] l10n_de_pos_res_cert: fix table orders loading error

[FW][FIX] account_reports: branch user access

[FW][FIX] l10n_mx_edi_pos: filter lines with zero price unit

[FW][FIX] hr_payroll_account_sepa: Avoid skipping bic on file generation

[FW][FIX] hr_contract_salary: Prevent rep fees proration for part times

[FW][WIP] mrp_workorder: add steps to operations

[FW][FIX] hr_contract_salary: Fix access right issue on configurator temp…