Odoo Changelog — 2024-02-07

Wednesday, February 7, 2024

47 changes · saas-17.1

Bug Fixes(1)

Resolved issues and error corrections

[FIX] web_studio: fix IconCreator list of icons

Enterprisesaas-17.1web_studio

The Web Studio icon picker now filters its icon list more accurately, so users no longer see icons that appear blank or cannot be applied correctly. This prevents confusion when choosing icons and keeps the available options reliable.

Original PR description

This commit is a fix for the FontAwesomeIconSelector component. The regex being used
didn't consider some added icons (using other font-family), or alterations of existing ones.

Such selectors ".fa.fa-tiktok:before" were matching, resulting in icons being present from
the list. But those icons cannot be used properly as a FontAwesome icon, since they may
use another font-family, or alter the content value described from the scss.

Now, only icons with selectors matching ".fa-[xxx]:before" are found, and the list no longer
display invisible icons.

#icons#web-studio#fontawesome

Other(46)

Miscellaneous changes

[FW][FIX] core: remove control characters from strings in xmlrpc

PR #153095

Coresaas-17.1base

Original PR description

According to https://docs.python.org/3.7/library/xmlrpc.client.html

> When passing strings, characters special to XML such as <, >, and & will be automatically escaped. However, it’s the caller’s responsibility to ensure that the string is free of characters that aren’t allowed in XML, such as the control characters with ASCII values between 0 and 31 (except, of course, tab, newline and carriage return); failing to do this will result in an XML-RPC request that isn’t well-formed XML.

**steps to reproduce:**
- create a product with an ASCII control character in its name (ex: \x03)
- read the product name using XMLRPC

**before this commit:**
- client can't parse the response, an error is raised 
`xml.parsers.expat.ExpatError: not well-formed (invalid token)
`

**after this commit:**
- we make sure the string is free of those characters

opw-3617458

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

Forward-Port-Of: odoo/odoo#152942
Forward-Port-Of: odoo/odoo#145577

This commit is a fix for the FontAwesomeIconSelector component. The regex being used didn't consider some added icons (using other font-family), or alterations of existing ones. Such selectors ".fa.fa-tiktok:before" were matching, resulting in icons being present from the list. But those icons cannot be used properly as a FontAwesome icon, since they may use another font-family, or alter the content value described from the scss. Now, only icons with selectors matching ".fa-[xxx]:before" are found, and the list no longer display invisible icons.

According to https://docs.python.org/3.7/library/xmlrpc.client.html > When passing strings, characters special to XML such as <, >, and & will be automatically escaped. However, it’s the caller’s responsibility to ensure that the string is free of characters that aren’t allowed in XML, such as the control characters with ASCII values between 0 and 31 (except, of course, tab, newline and carriage return); failing to do this will result in an XML-RPC request that isn’t well-formed XML. **steps to reproduce:** - create a product with an ASCII control character in its name (ex: \x03) - read the product name using XMLRPC **before this commit:** - client can't parse the response, an error is raised `xml.parsers.expat.ExpatError: not well-formed (invalid token) ` **after this commit:** - we make sure the string is free of those characters opw-3617458 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152942 Forward-Port-Of: odoo/odoo#145577

[FIX] web: SelectMenu issues The 1st commit fixes the style applied to the o_select_menu_sticky elements. Since the fix from commit (1), the text cursor is shown when hovering those elements. This was without considering the fact that this class is mainly used to display elements on top of other elements of the component. This includes usages with the bottomArea slot, that can be used with a DropdownItem. Because of the changes from the commit previously named, the focused color was no longer applied, and it was showing the wrong cursor when hovering. The 2nd commit fixes an issue caused by the way we use onInput props in Knowledge to fetch articles depending the current search value. Since we start from an empty string in the input again, it make no sense to display the choices previously fetched with a search value no longer displayed in the UI. The only way to display the correct items is to update the input value, then put an empty search to fetch accordingly. This is clearly an issue, when the onInput props is used to fetch the content of the SelectMenu, depending of the search value. The UI obviously display an empty search, and filter accordingly, but without having called the fetching of the items corresponding to the empty search value. A test was added as well to assert SelectMenu can be used for this purpose without forgetting to call onInput again when clearing the search value. Forward-Port-Of: odoo/odoo#152820

Since #135113, calls to /im_livechat/get_session can become very expensive on large databases with a long history of livechat sessions. Operators who have thousands of past livechat sessions (channels) can cause the SQL query in get_operator() to take multiple seconds. When the livechat is set to auto-popup and there are lots of visitors, this can become very significant. This patch changes two aspects: - introduce a CTE for the RTC session part, in order to avoid a JOIN cardinality explosion between livechat channels and channel_members - we only care about channel membership for a RTC session AFAICT - restrict the selection of livechat channels created **within the last 24h**, considering that we only care about messages sent in the last 30 minutes anyway The second part may change the result ordering in the presence of old channels (>24h) with recent messages - but that is rather unlikely, and an operator will be selected anyway. This change makes a huge difference on a database with 300k livechat channels and 1 million `discuss_channel_member` records, from several seconds to >50ms. The results are identical or extremely similar in most cases, and the database only needs to look at a few hundred records instead of millions. Forward-Port-Of: odoo/odoo#150968

When user gives wrong domain in any account report of report line and tries to access the same report similar error is generated. Steps to Produce: - Install 'Accounting' - Go to Accounting > Configuration > Accounting Reports - Open any account report and click on add a line - Now add a line in the report line - Create an expression select 'Computation Engine' as Odoo Domain. - In Formula add this domain [('code', '!=like', '620.%')] - And add Sub-Formula as 'sum' - Save the expression and also the report - Go to Reporting and select the above report Traceback will be generated See similar traceback:- ``` ValueError: Invalid leaf ('code', '!=like', '620.%') File "odoo/http.py", line 2123, in __call__ response = request._serve_db() File "odoo/http.py", line 1699, 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 1726, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) File "odoo/http.py", line 1927, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) File "odoo/addons/base/models/ir_http.py", line 190, in _dispatch result = endpoint(**request.params) File "odoo/http.py", line 716, in route_wrapper result = endpoint(self, *args, **params_ok) File "addons/web/controllers/dataset.py", line 30, in call_kw return self._call_kw(model, method, args, kwargs) File "addons/web/controllers/dataset.py", line 26, in _call_kw return call_kw(request.env[model], method, args, kwargs) File "odoo/api.py", line 461, in call_kw result = _call_kw_multi(method, model, args, kwargs) File "odoo/api.py", line 448, in _call_kw_multi result = method(recs, *args, **kwargs) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 3713, in get_report_information all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(self.line_ids.expression_ids, options) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2138, in _compute_expression_totals_for_each_column_group current_group_expression_totals = self._compute_expression_totals_for_single_column_group( File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2266, in _compute_expression_totals_for_single_column_group formula_results = self._compute_formula_batch(column_group_options, engine, date_scope, formulas_dict, current_groupby, next_groupby, offset=offset, limit=limit) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2546, in _compute_formula_batch return getattr(self, engine_function_name)( File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 2662, in _compute_formula_batch_with_engine_domain tables, where_clause, where_params = self._query_get(options, date_scope, domain=line_domain) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_analytic_report.py", line 173, in _query_get tables, where_clause, where_params = super(AccountReport, context_self)._query_get(options, date_scope, domain) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_report.py", line 1469, in _query_get query = self.env['account.move.line']._where_calc(domain) File "home/odoo/src/enterprise/saas-16.3/account_reports/models/account_analytic_report.py", line 259, in _where_calc query = super()._where_calc(domain, active_test) File "odoo/models.py", line 4695, in _where_calc return expression.expression(domain, self).query File "odoo/osv/expression.py", line 777, in __init__ self.parse() File "odoo/osv/expression.py", line 1083, in parse push(leaf, comodel, coalias) File "odoo/osv/expression.py", line 931, in push check_leaf(leaf, internal) File "odoo/osv/expression.py", line 726, in check_leaf raise ValueError("Invalid leaf %s" % str(element)) ``` ValueError: Invalid leaf ('code', '!=like', '620.%') When user applies invalid values in domain or invalid domain format it leads to the traceback because of this line: https://github.com/odoo/enterprise/blob/16.0/account_reports/models/account_report.py#L1510 sentry-4358342635,4909338331 Forward-Port-Of: odoo/odoo#151744 Forward-Port-Of: odoo/odoo#130981

Current behavior: --- If a customer has no email set, creating an invoice for that customer and clicking on send and print will not generate a snailmail for the invoice, even if, the checkbox (checkbox_send_by_post) is True. Expected behavior: --- A snailmail should be sent to the customer. Steps to reproduce: --- Create a customer invoice for a customer without email > print and send > check "By Post" > send and print. Cause of the issue: --- The action action_send_and_print defined in account_move_send.py filters the moves that trigger a mail creation in the var "success". This variable filters out all moves without a partner_id.email. This makes perfect sense for emails but not for snailmails. However, creations of both types of mails are triggered by the method "_hook_if_success" taking "success" as one of its argument. Fix: --- To allow snailmail creations and correctly trigger email creation, we filter the moves with a partner email after the method "_hook_if_success" and only for email creation, not for snailmails. opw-3668487 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#152506 Forward-Port-Of: odoo/odoo#149553

This shouldn't change anything regarding SEO, but is worth a try. It will also impact the link suggestion when creating a link in the editor, but having pages listed first also have sense there, or at least it won't be worst. The idea for the SEO part is that if the sitemap order (if too long) would have some impact as crawlers might have a limited crawling budget for your website and it will only crawl the first pages it finds. Are those "first pages" impacted by the sitemap order? It's almost sure it's not, as Google definitely knows how to crawl on its own, and is even probably ignoring the sitemap most of the time. Also, pages: - Are probably always important content since you created manually a page to write something, while (some) controllers might just be content you care less about. Pages are probably always important while we can't say that for controllers. - Should be fewer in number than controllers most of the time - Have a lastmod set, as opposed to controllers For all those reasons, this commit reverse the pages vs controllers order in the sitemap. This is coming from our prod where some pages are yet not indexed while they have been published months ago. Forward-Port-Of: odoo/odoo#152350

**Issue Description**: Users encounter a misleading confirmation page when a payment is canceled or fails in version 17.0 and higher of our website. Specifically, upon a payment error, users are directed to /payment/status with an error message. However, selecting the "Skip" button redirects them to a confirmation page titled "Thank you for your order", suggesting successful payment. This misleading information can lead to confusion, especially since it results in the card being cleared for public users despite non-receipt of payment. **Steps to Reproduce**: 1. Navigate to the 'Shop' section of the website, add a product to the cart, and proceed to checkout. 2. Click the "Pay with demo". 3. Select "Canceled" as the Payment Status and then "Pay". 3. Click the "Skip" button during the payment process. 4. Observe redirection to a confirmation page with the title "Thank you for your order", implying successful transaction. **Proposed Solution**: This issue, present in versions 17.0 and later, is due to a modification in the <template id="confirmation">, where the "Thank you for your order" title is now displayed regardless of the payment state. To resolve this, we propose introducing a conditional check to display this title only when the payment state is "done", ensuring accurate representation of the transaction status. opw-3688785 Forward-Port-Of: odoo/odoo#151304

### Steps to reproduce - Install **Payroll** app - Create two companies each belonging to different countries, for example: - Company A in US - Company B in AE - In **Company A**, create a salary structure with a salary rule that belong to Company A -US- - Using **Company A**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the **MEASURES** dropdown button, U can see the newly created salary rule. Try clicking on it. Everything works fine. - Now switch to **Company B**, create a salary structure with a salary rule that belong to **Company B** -AE- - Using **Company B**, In the payroll app, Go to > **Reporting** > **Payroll** and click on the MEASURES dropdown button, U can see the newly created salary rule. Try clicking on it. a DB error occurs. ### Investigation - When we create a new salary rule, we `_generate_payroll_report_fields()` https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/models/hr_salary_rule.py#L195 - Which `init()` the payroll report, creating a new DB view. However only the current company rules are fetched removing the other companies rules from the view as the old one is dropped https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L145 ### Discuss I think a better approach would be to construct a new view each time you open the payroll report, meaning to `init()` the report each time we go into https://github.com/odoo/enterprise/blob/b9adb690d7fd38c66a787377967a856b9678ffd1/hr_payroll/report/hr_payroll_report.py#L157-L165 but I think it's not a good idea to drop a view and create another each time also! opw-3675598 Forward-Port-Of: odoo/enterprise#55759 Forward-Port-Of: odoo/enterprise#55606

Steps to reproduce: ------------------- - install hr_payroll and hr_holidays; - create an employee; - create a contract for this employee (since 1st January for example); - create and approve a sick time off for this employee (for a day in January); - create a payslip for this employee (the payslip has two "worked days"); - confirm the payslip; - go to Reporting / Payroll and group by employee; - click on the employee's line to display the list view. Issue: ------ There are two records. This can be explained by saying that this is a record by worked days type. However, if we click on it, we see that the detail is the same for both records. Cause: ------ The query which generates the virtual table `hr_payroll_report` will give as `id`, the value of the `id` which corresponds to the payslip. ```sql SELECT p.id as id, wd.id as wdid, wd.name FROM (SELECT * FROM hr_payslip WHERE state IN ('done', 'paid')) p left join hr_payslip_worked_days wd on (wd.payslip_id = p.id) ``` The result of this query will be two records: ``` id | wdid | name ----+------+------------ 1 | 2 | Unpaid 1 | 3 | Attendance ``` When we want to obtain the details of the record, we will perform a read on the `hr.payroll.report` model for an `id` equal to 1 for both records, i.e. we will retrieve the same values. Solution: --------- Forcing the id to be unique. Add a field indicating the type to avoid confusion. Note: In the list view, it is possible to group by "Payslip Name" to avoid confusion. Note 2: It is a band-aid fix that helps us understand what is going on in the report, but it needs to be redesigned to redirect us directly to payslip records and not records corresponding to worked days (and avoid aggregation problems). opw-3686692 Forward-Port-Of: odoo/enterprise#55882 Forward-Port-Of: odoo/enterprise#55629

Bug Fixes(1)

[FIX] web_studio: fix IconCreator list of icons

Other(46)

[FW][FIX] core: remove control characters from strings in xmlrpc

Bug Fixes(1)

[FIX] web_studio: fix IconCreator list of icons

Other(46)

[FW][FIX] core: remove control characters from strings in xmlrpc

[FW] Saas 16.4 web fix selectmenu bottom area luvi

[FW][FIX] mail: give additional values for partner creation

[FW][IMP] 16.0 l10n_es_edi_tbai support out invoices with taxes of type "retención"

[FW][IMP] im_livechat: speed up operator selection

[FW][FIX] website_sale: Fix poor quality image tags

[FW][FIX] l10n_in: fix gst treatment on posted invoice

[FW][FIX] project: sharing, restrict child_ids an tag_ids for portals

[FW][FIX] website_sale: set border color on color attribute

[FW][IMP] l10n_ro_edi, base_vat: Tin numbers

[FW][FIX] event: support early entrance

[FW][FIX] analytic: can't create plan with access.

[FW][FIX] payment_mercado_pago: handle mercado pago no body responses

[FW][FIX] web_editor: checklist direction does not switched for nested checklist

[FW][FIX] l10n_in: make invoice template primary

[FW][FIX] point_of_sale: prevent printing empty page

[FW][IMP] website_sale: hide price range by default

[FW][FIX] portal: alignment problem with attachment in dialog box

[FW][FIX] payment_stripe: fix express checkout total amount computation

[FW][FIX] payment_stripe: fix truncated express checkout button

[FW][FIX] point_of_sale: Remove the upgrade during the iot build

[FW][FIX] website_sale: remove scroll visibilty in filter

[FW][FIX] account: handle error when incorrect domain is passed in account report

[FW][FIX] l10n_es_edi_facturae: fix signature

[FW][FIX] hr_attendance: change logo route in kiosk

[FW][16.0][FIX] account: Use context_today instead of today

[FW][FIX] *: use correct float formatter

[FW][FIX] website_slides: resolve slides completion status issue

[FW][FIX] snailmail_account: generate snailmail

[FW][FIX] l10n_it_edi: Errors in warnings_message -> actionable errors migration code

[FW][IMP] analytic: index the dynamic plan columns

[FW][FIX] account: performance of smart search on journal entries

[FW][FIX] account: bring back cumulated balance

[FW][IMP] website: list pages before controllers in sitemap

[FW][FIX] website_sale: title on non done confirmation

[FW][FIX] website: fix removing a local google font

[FW][ADD] l10n_in_qr_code_bill_scan: add QR code scanning functionality for vendor bills (India)

[FW] FIX] sale_subscription: ensure test is not failing in february

[FW][FIX] planning: group increments by instant

[FW][FIX] hr_payroll: preserve existing salary rules when generating new payroll reports across multi-company

[FW][FIX] appointment: don't add retrocompatibility urls in sitemap

[FW][FIX] sign: translate ecological report + fix English

[FW][FIX] *: use correct float formatter

[FW][FIX] hr_payroll: force unique id in the report

[FW][FIX] documents, documents_account: fix the tours

[FW][FIX] l10n_au_hr_payroll: Fix demo data and tests