Daily updates from Odoo
Saturday, November 30, 2024
13 changes · 18.0
Resolved issues and error corrections
Incoming call invitation pop-ups now keep a consistent dark background with white text, instead of appearing transparent or switching to a bright style in dark mode. This makes call notifications easier to read and reduces visual discomfort for users using dark theme.
Original PR description
Call invitation was transparent because text-bg-900 is a backend-specific classname style. As a result, the pop-up had no bg-color. Also the background color and text looks good in white theme: black background with white text. This matches the colors in the call view. In dark theme the colors were inverted: white background and black text. This is unintentional, because this doesn't match call view color that is black color and white text in dark theme too. Also the main advantage of dark theme is to put less eye strain and the inverted colors in dark theme were actually more eye-straining than white theme. This commit fixes the issue by putting specific color in CSS. These colors should not change with theme: dark theme should keep dark background and white text. task-4354214
Loading a new chart of accounts for a company no longer deletes accounting records that are shared with other companies. This prevents one company’s setup changes from accidentally disrupting accounting configurations used elsewhere.
Original PR description
When loading a chart template on a root company, we check whether any journal items have already been created for the company, and if not, we delete the existing accounting configuration before loading the new CoA. However, we must take care in the case of records that are shared between several companies, to just unlink them from the active company, rather than delete them (which would affect other companies as well). This commit fixes that. task-none
LinkedIn hashtag links generated from social posts now use LinkedIn's current link format. This helps ensure hashtags, including edge cases like short or mixed formats, open correctly for users viewing LinkedIn content.
Original PR description
With the current links generated for the hashtags in Linkedin, there's a few corner cases that are not being handled by Linkedin side as we expect it to (ex #FLD), so from 18.0 onwards we should follow the same formatting Linkedin is using nowadays. Previous link: https://www.linkedin.com/feed/hashtag/FLD2024 Link after the change: https://www.linkedin.com/feed/hashtag/?keywords=FLD2024 In the previous links you can see the differences between them. opw-4326960
Mexican global invoices can now be created from invoices or POS orders in a foreign currency, as long as all selected documents use the same currency. This prevents unnecessary blocking for valid USD or other foreign-currency transactions while still avoiding mixed-currency global invoices.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and switch to Mexican company 2. Create a POS Order or an Invoice in USD 3. Select the Order/Invoice and create a Global Invoice 4. Receive the error: > You can't process orders having a foreign currency. or > You can't process invoices having a foreign currency. ### Explanation: The intended behaviour, blocking multicurrency on Global Invoicing, was explained as an interdiction on foreign currencies. ### Fix reasoning: Intended behaviour is to block the user when all `pos.order` or `account.move` do not have the same `currency_id`. opw-4302180
Documentation and clarification updates
This pull request records that Kripal has signed the Contributor License Agreement. It is an administrative/legal update that helps ensure contributions can be accepted under Odoo's project rules.
Original PR description
Description of the issue/feature this PR addresses: This PR adds CLA signature. 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
This pull request records Kripal's confirmation of signing the Contributor License Agreement. It is an administrative compliance update that supports contribution eligibility and does not change product behavior.
Original PR description
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
Miscellaneous changes
Revert the following fix: https://github.com/odoo/odoo/commit/5e3b471f4a67553d6f7525595b15dc3d7b4efb3f Which is no longer necessary since we have streams: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac In particular, media must be returned with code 206 and a range, which is now the case. Forward-Port-Of: odoo/odoo#189063 Forward-Port-Of: odoo/odoo#188872
Original PR description
Revert the following fix: https://github.com/odoo/odoo/commit/5e3b471f4a67553d6f7525595b15dc3d7b4efb3f Which is no longer necessary since we have streams: https://github.com/odoo/odoo/commit/da8def8e410de68256ba4ab09ebf7a8b699355ac In particular, media must be returned with code 206 and a range, which is now the case. Forward-Port-Of: odoo/odoo#189063 Forward-Port-Of: odoo/odoo#188872
In the purchase tab of the sale view, the user can see UoMs of all categories for the vendor bill, but can only pick the one in the same category as the sales price unit, as other options will get silently reverted by an onchange. This is logical, but confusing for the user. The addition of a domain for the UoM category prevents units of other categories from appearing in the view. Partial backport of 33d7474b07abf8ae161364bcf29ae72cd04384ba opw: [4212814](https://www.odoo.com/odoo/project
Original PR description
In the purchase tab of the sale view, the user can see UoMs of all categories for the vendor bill, but can only pick the one in the same category as the sales price unit, as other options will get silently reverted by an onchange. This is logical, but confusing for the user. The addition of a domain for the UoM category prevents units of other categories from appearing in the view. Partial backport of 33d7474b07abf8ae161364bcf29ae72cd04384ba opw: [4212814](https://www.odoo.com/odoo/project/966/tasks/4212814) Forward-Port-Of: odoo/odoo#187857
In safari (and all webkit navigators) `HTMLCanvasElement.toDataUrl` does not support `image/webp` as `type` parameter. https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL#browser_compatibility Before this commit, spreadsheet_edition/hooks.js:useSpreadsheetThumbnail draws an image to a canvas and convert it to base64. But the code assumes that the conversion to webp will work. `toDataUrl` uses `png` type if it doesn't work https://developer.mozilla.org/en-US/do
Original PR description
In safari (and all webkit navigators) `HTMLCanvasElement.toDataUrl` does not support `image/webp` as `type` parameter. https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL#browser_compatibility Before this commit, spreadsheet_edition/hooks.js:useSpreadsheetThumbnail draws an image to a canvas and convert it to base64. But the code assumes that the conversion to webp will work. `toDataUrl` uses `png` type if it doesn't work https://developer.mozilla.org/en-US/docs/Web/API/HTMLCanvasElement/toDataURL#type With this commit, the regexp that removes the encoding data will supports `webp` **and** `png` Forward-Port-Of: odoo/enterprise#74870
Problem: ======== when using pacs : Quadrum, SW Sapien some clients get their CFDI rejected because the schemaLocation is is containing more headers than needed. Solution: ========= We will only keep the needed schemaLocation for customer invoice, so headers for Payment and External Trade will be removed. opw-4168509 Forward-Port-Of: odoo/enterprise#74402 Forward-Port-Of: odoo/enterprise#72450
Original PR description
Problem: ======== when using pacs : Quadrum, SW Sapien some clients get their CFDI rejected because the schemaLocation is is containing more headers than needed. Solution: ========= We will only keep the needed schemaLocation for customer invoice, so headers for Payment and External Trade will be removed. opw-4168509 Forward-Port-Of: odoo/enterprise#74402 Forward-Port-Of: odoo/enterprise#72450
Reproduce --- - -i social - Social Marketing -> Add Stream - Add post -> give it a like on linkedin - BUG: Like information not fetched opw-4190850 Forward-Port-Of: odoo/enterprise#72491
Original PR description
Reproduce --- - -i social - Social Marketing -> Add Stream - Add post -> give it a like on linkedin - BUG: Like information not fetched opw-4190850 Forward-Port-Of: odoo/enterprise#72491
The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow. In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each ro
Original PR description
The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is…
The query in `_get_invoice_matching_so_candidates` will frequently plan a Seq Scan because of the low selectivity of the conditions. And when it does not, the number of rows returned by the CTE is expected to high. Because of that, filtering the resulting rows by a sequence of `OR` conditions can quickly become slow. In this commit, the `OR` conditions are replaced by `LIKE(ANY(ARRAY[]))` conditions. That way the CTE is only referenced once in the conditions and applying the filter on each row is way faster. We also discarded duplicated `text_tokens` to reduce the size of the `ARRAY`. The reason why using a `LIKE(ANY(ARRAY[]))` is faster is because postgres inlines the CTE in the outer query. This means that it performs a Seq Scan on sale.order and injects the CTE definition of sub.name inside the `WHERE` conditions of the outer query, along with injecting the `WHERE` conditions of the CTE. So, the regex functions are distributed among the `OR` conditions. I.e. every `OR` condition left operand will contain the regex functions. As those have to be executed for every `OR` condition, this quickly becomes slow. We can explicitely materialize the CTE to avoid that. This makes postgres evaluate the regex functions only once. But it will still have lots of `OR` conditions to check along with running pattern matching for each one of them. `LIKE(ANY(ARRAY[]))` avoids this issue. The CTE is still inlined but since we now only have a single condition, the regex functions are only evaluated once and pattern matched once against an array of options. This makes the whole query faster and scale better. #### speedup Customer database with 808341 sale.orders. Query timing when increasing the number of text tokens. | Number of tokens | Before PR | After PR | |:-------------------:|:----------:|:--------:| | 2 | 7s | 1.3s | | 5 | 10s | 1.3s | | 10 | 18s | 1.4s | | 20 | 33s | 1.55s | opw-4329067 opw-4316765 Forward-Port-Of: odoo/enterprise#74827 Forward-Port-Of: odoo/enterprise#73755
This commit fixes an issue with the social_linkedin module's comments fetch methods introduced in https://github.com/odoo/enterprise/pull/67079. This method disconnects the user from its account every time they open a post's comments, even if all API calls are successful. This shouldn't happen as nothing wrong happened to warrant a disconnection on our end. Now the user's account is disconnected if and only if there was an actual issue when fetching comments. task-4363737 Forward-Port-Of
Original PR description
This commit fixes an issue with the social_linkedin module's comments fetch methods introduced in https://github.com/odoo/enterprise/pull/67079. This method disconnects the user from its account every time they open a post's comments, even if all API calls are successful. This shouldn't happen as nothing wrong happened to warrant a disconnection on our end. Now the user's account is disconnected if and only if there was an actual issue when fetching comments. task-4363737 Forward-Port-Of: odoo/enterprise#74672