Odoo Changelog — 2024-03-22

Friday, March 22, 2024

52 changes · saas-17.1

Bug Fixes(4)

Resolved issues and error corrections

[FIX] point_of_sale: prevent error when clicking on optional product

Coresaas-17.1point_of_sale

Point of Sale users can now click optional products in the product information popup without encountering an error. This keeps the sales flow smoother and avoids interruptions caused by a missing action after a recent refactor.

Original PR description

Before this commit, clicking on an optional product in the product info popup would cause an error. This was due to the absence of the `setSelectedCategoryId` function, which was removed during the refactor.

opw-3815392

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

#point of sale#optional products#product popup#sales flow

[FIX] sale_planning: does not override planned dates in default values

PR #59247

Enterprisesaas-17.1sale_planning

Creating a shift from a specific cell in the planning Gantt view now keeps the selected date instead of defaulting to the full visible calendar period. This prevents users from having to manually correct planned dates and restores the expected scheduling behavior.

Original PR description

Before this commit, when the user clicks on a gantt cell of the planning gantt view to create a shift for a specific date. By doing that, the planned dates set by default to the form view is the whole period of the gantt view instead of the date set on the gantt cell clicked.

This commit removes the override erasing the default planned dates by the period of the gantt to keep the standard behavior as before.

#planning#gantt#scheduling#default dates

[FW][FIX] point_of_sale: enable report generation with multi bank payments

PR #157701

Coresaas-17.1point_of_sale

This update resolves an issue preventing sale reports from generating correctly when multiple bank accounts were used for a payment. The previous system required a single account payment, which is now corrected. This ensures accurate reporting for all sales transactions, regardless of payment method.

Original PR description

Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton.

opw-3799171

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

Forward-Port-Of: odoo/odoo#157426

#reporting#payments#sale

[FW][FIX] pos_restaurant: US tipping should not be set by default

PR #158120

Coresaas-17.1pos_restaurant

This update fixes a default setting in the restaurant POS module that was incorrectly configured for US customers in the SaaS environment. Previously, the system automatically enabled tipping after payment, regardless of the user's country. This change ensures a better experience for all users by removing the US-specific default.

Original PR description

In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them.

We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore.

Forward-Port-Of: odoo/odoo#149542

#pos#tipping#saas#default

Other(48)

Miscellaneous changes

[FW][FIX] account_peppol: handle participant not ready error

PR #158865

Coresaas-17.1account_peppol

Original PR description

### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an…

### [FIX] account_peppol: handle participant not ready error

If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages.

### [FIX] account_peppol: mock external request

Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped.


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

Forward-Port-Of: odoo/odoo#158546
Forward-Port-Of: odoo/odoo#154926

Before this commit, clicking on an optional product in the product info popup would cause an error. This was due to the absence of the `setSelectedCategoryId` function, which was removed during the refactor. opw-3815392 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit, when the user clicks on a gantt cell of the planning gantt view to create a shift for a specific date. By doing that, the planned dates set by default to the form view is the whole period of the gantt view instead of the date set on the gantt cell clicked. This commit removes the override erasing the default planned dates by the period of the gantt to keep the standard behavior as before.

Following commit https://github.com/odoo/odoo/commit/d9190e34543c4a1151656859acb41556bcb3a364, generating a sale report became impossible if a session had more than one account payment. This was due to a ValueError: Expected singleton. opw-3799171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157426

In SaaS, the DB is pre-prepared with the generic chart of accounts before the new user finishes the form. Since the default country of the generic chart of accounts is the US, then `set_tip_after_payment` option in the pre-created pos.config is set to True. Now, when the form is submitted, the country is identified but the said option remains to be True. This is a problem because not all customers are creating an odoo instance for a US company. So customers from other countries will have the option activated by default which is not a good default for them. We introduced this behavior in aa1c5b53bf131c6df96ad621e00bd2ee3d44c6c0 and in this commit we won't set the option by default anymore. Forward-Port-Of: odoo/odoo#149542

### [FIX] account_peppol: handle participant not ready error If the participant is not active on the IAP server, the server sends back a Participant not ready error in response without raising an error. On the client side a user sees a traceback, because we're trying to retrieve a message uuid of a non-existent peppol message: `response['messages'][i]['message_uuid']`. That's because we treat that error in the try block and then proceed to the else block because technically there was no exception. This commit moves that error handling to `else` block so that such invoices get the proper error messages. ### [FIX] account_peppol: mock external request Now that we check whether a participant exists on Peppol network first when they register, we should also mock that request. Currently, since that request is not mocked, all peppol tests are skipped. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158546 Forward-Port-Of: odoo/odoo#154926

If the 'cancel next move' feature is enabled, canceling a SOL could lead to unexpected picking creation To reproduce the issue: (Debug mode enabled) 1. In Settings, enable "Multi-Step Routes" 2. Edit the warehouse: - Outgoing shipments: 2 steps 3. Edit the delivery route: - For each rule: - Cancel next move: True 4. Confirm a SO with one product 5. Set the SOL quantity to 0 Error: A third picking is created, from customer to output location Step 4, it creates two SM: \- SM_SO: from Stock to Ouput \- SM_OC: from Output to Customer Step 5, thanks to the procurement process, we create a stock move: \- SM_OC_neg, from Output to Customer with a negative qty. While confirming this SM, and thanks to the same process, we then create a second stock move : \- SM_SO_neg, from Stock to Output, with a negative qty. Both negative SM are linked. While confirming SM_SO_neg, we merge it with SM_SO. Therefore: \- Dest moves of SM_SO_neg are given to SM_SO \- SM_SO_neg is deleted (fully absorbed by SM_SO) \- SM_SO has now a zero demand, so we cancel it: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1024-L1025 However, because of step 3, we also cancel its dest moves: https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1740-L1745 i.e., we cancel SM_OC *and* SM_OC_neg. This leads to an inconsistency: Back to the confirmation of SM_SO_neg. As explained, this SM has been canceled during the procurement process. Still, we keep processing its confirmation (we overwrite its state, we assign it to a picking, and so on). Hence the error. In `_merge_moves`, when deleting a stock move, we first clean it (for instance, we disable the cancel propagation): https://github.com/odoo/odoo/blob/bd7aadf589ef1ba4556164bc70fc0fbb62928e48/addons/stock/models/stock_move.py#L1018-L1020 We should do the same with SMs we are going to cancel. That way, we fix the root cause of the issue: when cancelling SM_SO, we don't cancel neither SM_OC neither SM_OC_neg, so we don't have any inconsistency when going back to the confirmation of SM_SO_neg, and everything will work correctly. OPW-3753453 Forward-Port-Of: odoo/odoo#158663 Forward-Port-Of: odoo/odoo#158562

Before this commit, the header was considered as mobile at the `SM` screen breakpoint, while it is already displayed as in mobile view at `MD`. This made some of the header behaviors inconsistent: 1) A menu open at `MD` is not closed when resizing the screen: - Resize the screen at `MD` and open the menu. - Resize the screen above `LG`. - Resize back at `MD`. => The menu was not closed. It is when we start resizing at `SM`, which is inconsistent as they are both displayed like in mobile view. 2) The menus are hoverable at `MD` but not at `SM`: - Add sub-menus and mega menus with the menu editor. - In edit mode, set the menus as hoverable (set the "Sub Menus" option to "On Hover") and save. - Hover the menus: - above `LG` (= desktop view) => they open. - under `SM` (= mobile view) => they do not open because we need to click to open them on mobile view. - between `SM` and `LG` => they open even though it is displayed like in mobile view, so the behaviors are inconsistent. This commit considers the header as mobile under the `LG` screen breakpoint, to uniformize the behaviors of the mobile header. task-3801970 Forward-Port-Of: odoo/odoo#158571 Forward-Port-Of: odoo/odoo#157601

There are currently translation issues related to the chart template. Due to this the names of some records do not receive the necessary / intended translations when installing a localization or new language. When installing a new localization / chart some records have the following problem with the values of their translatabe fields: They are only installed in the language that was active when the localization / chart was installed. Thus when switching languages (or using a different user with a different language) the names are displayed in the "installation language". Translations for all active languages should be installed (for all relevant records). The same problem happens when installing a new language (the same records do not receive a translation for the new language). The translation issue concerns for example (some) accounts and journals; see the (incomplete) list at the end of this message. This commit tries to fix the translation issue for the translatable fields of all relevant models. Note! ===== * The translation mechanism only works for records with xmlid. If a module creates a record without xmlid it will not be translated. * The problem is only fixed for records with xmlid for which at least 1 of the following conditions holds: * The record (and the translatable field value) is defined in the body of the function decorated with 'https://github.com/template' * The translation of the value of the translatable field can be found in the module 'account' or in the module that is associated with the record (by 'ir.model.data') I.e. the problem is not solved for demo data: It is technically difficult to determine the module they originate from. This makes it difficult to load the right code translation (the module information is needed for this). * The translation mechanism is not necessarily triggered if the record is (in principal) part of the chart template but not installed as part of the chart template. This can i.e. happen if a module is installed after the localization / chart. * Example: account.journal "Salaries" from hr_payroll_account * We also want to "translate" / localize some untranslatable fields (like account journal codes). For these fields the terms will be installed in the language of the partner of the company for which the chart will be installed (fallback to lang / user lang from the env in case there is none set) * Currently there is no language set for many (all?) demo comany. Thus the values will remain in English for them (when the respective module is installed). Examples / Details ================== **Reproduce**: 1. Switch to the French language (install if needed) (Settings App > General Settings > Languages) 2. Install a localisation (e.g. l10n_fr). 3. Check the French translations of the localization * Comptabilité > Configuration (Menu) > Journaux (Accounting > Configuration (Menu) > Journals) * Here the journal names are in French * Comptabilité > Configuration (Menu) > Plan comptable (Accounting > Configuration (Menu) > Chart of Accounts) * All the account names are in French 4. Switch to English on the current user (or some other language) via the user profile on the top right. 5. Check the names of the localization again * Accounting * The journal names are still in French * Accounting > Configuration (Menu) > Chart of Accounts * Some of the account names are still in French * E.g. "Compte d'attente de la banque" ("Bank Suspense Account") Other things to test: * "Salaries" journal from enterprise module 'hr_payroll_account' * Not demo data; it will (partly) work after this commit (see "Note" above) * "IFRS Automatic transfers" journal from enterprise module 'account_auto_transfer' (installed when installing l10n_fr) * Demo data; the problem remains after this commit **Technically** the main problems are the following: 1. The information of some of the created records is only defined in the code. Thus their translations have to be taken from the translation of the code. But at the point of translation it is not clear from which module the data came from. This is needed to load the right translation. * This was fixed for data from 'https://github.com/template' functions 2. Some records are created without an xmlid and thus cannot be translated with the current translation mechanism at all. * This was fixed for the relevant records from module 'account' Example Records --------------- Some affected **accounts**: * from module 'account' * Bank utility accounts * Bank Suspense Account * Outstanding Receipts * Outstanding Payments * Cash Discount Loss * Cash Discount Gain * Cash Difference Loss * Cash Difference Gain * Liquidity Transfer * Bank / Cash journal default accounts * Bank * Cash * Unaffected earnings account * Undistributed Profits/Losses Some affected **journals** * from module 'account' * Customer Invoices * Vendor Bills * Miscellaneuos Operations * Exchange Difference * Cash Basis Taxes * Bank * Cash * from module 'account_auto_transfer' (enterprise) * IFRS Automatic Transfers * The problem will remain since it is demo data * from module 'hr_payroll_account' (enterprise) * Salaries * The translation is only loaded if the module is installed before the localization / chart task info ========= task-3414329 Forward-Port-Of: odoo/odoo#158382 Forward-Port-Of: odoo/odoo#137592

This issue is occurring when the user tries to add a `VAT` number, while creating a new contact To reproduce this issue: 1) Install `contacts` and `partner_autocomplete` 2) Create a new contact from `Contacts` 3) Give a valid `VAT` number e.g:- `SK2120312645`(got it from sentry) 4) Traceback occurs in the terminal Error:- ``` IndexError: list index out of range File "odoo/http.py", line 2251, in __call__ response = request._serve_db() File "odoo/http.py", line 1826, in _serve_db return self._transactioning(_serve_ir_http, readonly=ro) File "odoo/http.py", line 1847, in _transactioning return service_model.retrying(func, env=self.env) File "odoo/service/model.py", line 134, in retrying result = func() File "odoo/http.py", line 1824, in _serve_ir_http return self._serve_ir_http(rule, args) File "odoo/http.py", line 1832, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 2057, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 740, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 34, in call_kw return self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 30, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 458, in call_kw result = getattr(recs, name)(*args, **kwargs) File "addons/partner_autocomplete/models/res_partner.py", line 158, in read_by_vat 'city': zip_city[1], ``` In some cases, the expected `zip_city` value is not at the last of the address list , which leads to above traceback. As `zip_city` must contain both zip and city values. https://github.com/odoo/odoo/blob/382b64c2f14073cfff1a8ef9290b5c7834d52188/addons/partner_autocomplete/models/res_partner.py#L143-L156 After applying this commit will resolve this issue by searching `zip_city` based on regex. sentry-5058467547 Forward-Port-Of: odoo/odoo#158368 Forward-Port-Of: odoo/odoo#157697

Uses `product_category_name` instead of `categ_id` when deciding how to sort SMLs in the barcode picking view. Previously, `categ_id` was used for sorting, however there are two issues with that: 1.) This would sort by the ID, not the name, which is probably not expected behavior. 2.) `categ_id` is actually always undefined in the `_sortingMethod` call because it is never passed into the front end in the first place. This fix adds `product_category_name` as a field to be read from the `stock.move.line` within the `_get_stock_barcode_data` method of `stock_barcode/models/stock_picking.py`. It also changes `categ_id` to `product_category_name` with the `_sortingMethod` method of `stock_barcode/static/src/models/barcode_model.js` As a final note, I am unsure if `categ_id` should be removed from the [`_get_fields_stock_barcode` method in `stock_barcode/models/product_product.py`](https://github.com/odoo/enterprise/blob/5b2fb8d0f3baf4fdc13e9399061110e06e3c76da/stock_barcode/models/product_product.py#L19). In this context it should be removed, however I'm unsure if other code may use it, and for compatibility sake it would be best to leave it there. opw-3693232 Forward-Port-Of: odoo/enterprise#59169 Forward-Port-Of: odoo/enterprise#56633

Bug Fixes(4)

[FIX] point_of_sale: prevent error when clicking on optional product

[FIX] sale_planning: does not override planned dates in default values

[FW][FIX] point_of_sale: enable report generation with multi bank payments

[FW][FIX] pos_restaurant: US tipping should not be set by default

Other(48)

[FW][FIX] account_peppol: handle participant not ready error

Bug Fixes(4)

[FIX] point_of_sale: prevent error when clicking on optional product

[FIX] sale_planning: does not override planned dates in default values

[FW][FIX] point_of_sale: enable report generation with multi bank payments

[FW][FIX] pos_restaurant: US tipping should not be set by default

Other(48)

[FW][FIX] account_peppol: handle participant not ready error

[FW][FIX] purchase: fallback to standard price if no pricelist

[FW][FIX] payment_razorpay: fix `The phone number is invalid` for POS online payment

[FW][FIX] point_of_sale : printing expected shipping date on receipt

[FW][FIX] website_blog: prevent helpdesk module to mess with blog perf tour

[FW][FIX] sale,purchase,account,hr_expense: prevent wrap of taxes

[FW][FIX] account: do not show alert on posted invoice/bill

[FW][FIX] website: avoid considering utm cookies as required

[FW][I18N] point_of_sale: make some terms translatable

[FW][ADD]l10n_es new tax IRPF 24 rendimientos del capital

[FW][FIX] purchase_mrp: calculate valuation unit_cost correctly

[FW][FIX] l10n_br_pix: include dummy reference when none is set

[FW][FIX] l10n_se: invert values of block F and G of Swedish tax report

[FW][FIX] {sale_,}stock: avoid cancel propagation

[FW][FIX] l10n_sa_edi: missing reason when reversing entries

[FW][FIX] hr_holidays: keep duration display updated

[FW][FIX] website_event_meet: community page customize options

[FW][FIX] website: consider header as mobile under `LG` screen breakpoint

[FW][FIX] account: fix default taxes on product from branch

[FW][FIX] account: Prevent deleting basic accounting pdf reports

[FW][FIX] delivery: Prevent Deliveries product category deletion

[FW][IMP] stock_account: adapt test so only the value of the revaluation is checked

[FW][FIX] web_editor: table should not preserve its height and width

[FW][FIX] web: prevent double translations in views

[FW][FIX] account: fix some translations related to chart template

[FW][FIX] web_editor: remove image to save when removing background image

[FW][CLA] Update Vauxoo's CLA adding CLaurelB

[FW][FIX] purchase: tax inactives not shown on search

[FW][FIX] l10n_it_edi_website_sale: correct and translate terms

[FW][IMP] hr_holidays: make allocation duration editable

[FW][FIX] l10n_ch: tax report box 200 computation fix

[FW][IMP] l10n_de: Fixed taxes with wrong tax group

[FW][FIX] partner_autocomplete: fix traceback in vat number matching

[FW][FIX] base_address_extended: sync city_id with children contacts

[FW][FIX] website_event, *: fine tune the design

[FW][FIX] account: keep the sequence consistent if canceled

[FW][FIX] l10n_us_1099: opw-3774654

[FW][FIX] web_studio: include hoisted fields in kanban

[FW][FIX] l10n_se_reports : update test as report changed

[FW][FIX] account_reports: xlsx export and option companies

[FW][FIX] stock_barcode: consider product_category_name in sort order

[FW][FIX] approvals: Use purchase description in approval line

[FW][IMP] l10n_ar_edi: Improved error message

[FW][FIX] knowledge: redirect users to the article they were reading after signing in

[FW][FIX] l10n_co_edi: Add sugar tax groups - put template data into CSV

[FW][IMP] account_online_synchronization: Send totpenabled

[FW][FIX] l10n_ee_reports: KMD INF and VD report fixes

[FW][IMP] l10n_br_avatax: add documentation link in settings