Daily updates from Odoo
Navigate
Branch
Saturday, November 22, 2025
62 changes
15 changes
Enhancements to existing features
The system now ensures a buyer record exists on ECPay before sending a B2B invoice. This reduces invoice submission failures for customers who were not previously registered, and adds VAT validation earlier in the process to catch issues sooner.
Original PR description
This commit aims to address an edge case where the buyer identifier might not exist on ECPay before issuing a B2B invoice. A call to "Add" a customer is made. RtnCode 1 indicates successful creation, 6160052 - indicates buyer already exists, others are failure. Additionally, add "base_vat" as dependency to enable client-sided validation for VAT before sending to ECPay. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236826
This update corrects how tax amounts are computed in the Indonesian Coretax e-invoice export, so the generated XML matches the right tax groups instead of relying on invoice type in some cases. It also adds a validation rule to prevent invalid tax combinations, reducing the risk of incorrect e-invoice data being sent.
Original PR description
Update Coretax XML file to compute the values for nodes in the correct way. Currently the computation is based on the invoice type for some of the nodes + STLG is based on wrong tax group. This leads to wrong computation of values + inflexibility. - Update the VAT calculation inside the E-faktur XML based on tax group - Add new tax group and modify existing tax - Add restriction when downloading E-faktur Coretax XML Task [#4948267](https://www.odoo.com/odoo/project.task/4948267) Forward-Port-Of: odoo/odoo#236821 Forward-Port-Of: odoo/odoo#233347
This update stores Japanese state names directly in Japanese instead of relying on translations. It also adjusts the state codes to match ISO standards, improving consistency and making location data more accurate for users in Japan.
Original PR description
Since state names are not handled by translations, storing them directly in Japanese provides a better user experience. This **PR** updates the existing Japanese state records with their native Japanese names. Additionally, it aligns the state codes as per ISO standards. **task**-5345872 Forward-Port-Of: odoo/odoo#236649
Resolved issues and error corrections
This update corrects the Balance Sheet report so its linked cross-report lines respect the selected date range. As a result, the report shows more accurate figures when users compare or drill into balances for a specific period.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
Odoo now uses the updated official state code for Odisha in India. This helps ensure customer details and sales documents use the correct regional information and avoids mismatches when creating orders.
Original PR description
**Steps to reproduce:** 1. Install the `Contacts` module. 2. Go to Contacts > Create a new contact. 3. Select country India, and state Odisha. 4. Create a sales order using the newly created contact. **Issue:** As per [Government of India](https://www.iso.org/obp/ui/#iso:code:3166:IN), the state code was officially changed from "OR" to "OD" in 2023. However, Odoo still uses the outdated code. <img width="407" height="163" alt="image" src="https://github.com/user-attachments/assets/1631a831-f455-4a51-886f-7e4ed691add0" /> **Solution:** Update the name of the state from "OR" to "OD" in state records. **opw-4935633** Forward-Port-Of: odoo/odoo#234697
This update prevents a crash when reopening the website theme editor after using some Google Fonts that only offer one font weight. It ensures those fonts are loaded correctly so users can continue editing the theme without interruption.
Original PR description
Steps to reproduce: =================== 1. Edit the website theme and set an external font, e.g., UnifrakturCook. 2. Save, exit, then reopen the editor and go to the Theme tab. → Traceback occurs. Cause: ====== Some Google Fonts (e.g., UnifrakturCook) only provide a single weight (700). When fetching the font, html_builder does not request a specific weight, so Google Fonts attempts to return the default set, including 300. Since that weight does not exist for these fonts, Google Fonts responds with an error, leading to the traceback. This issue is same to the one fixed here: https://github.com/odoo/odoo/commit/f843c591c0377e0dab1a1f0cfaca36c1981c8880 but the fix was not ported during refactoring. opw-5259891 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an error that could appear when a user had several companies selected and refreshed the OSS mapping for one active company. The refresh action now correctly runs on the intended company, preventing a crash and keeping the workflow usable.
Original PR description
To reproduce: - Activate multiple companies in the selector - Enable OSS on the active company - Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies. Forward-Port-Of: odoo/odoo#236103
This fix ensures the annual corporate tax return uses the company’s actual fiscal year dates when a fiscal period is longer than one year. As a result, the tax return dashboard will show the correct closing period and deadline, avoiding an incorrect return being created for the wrong year.
Original PR description
Steps to reproduce: - Define a specific Fiscal Year with a start date on the 09/01/2025 and an end date on the 12/31/2026. So basically a custom fiscal period longer than a year. - Then, in the Tax Return journal, select the same start date 09/01/2025 and a fiscal year end on the 31 December. - Check Tax return dashboard, we have an "Annual Closing: Corporate Tax 2025", which shouldn't appear. - We should have an annual closing for 2026 with a deadline on the 31/07/2027. The aim of this commit is making sure that for the Annual Corporate Tax Return, we are using the fiscal year date_from / date_to to set the date_from / date_to of the return. opw-5165432 Forward-Port-Of: odoo/enterprise#100034
This update fixes how the mail module simulates browser settings in automated tests. It ensures the test helper is used with the right platform information, which helps keep test behavior accurate and prevents misleading results.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/odoo#236837Importing CSV files encoded in UTF-16 now fails with a clearer warning instead of a technical decoding error. This makes it easier for users to understand what went wrong and correct the file or encoding setting.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266 Forward-Port-Of: odoo/odoo#226023
This fix ensures German Datev export files reflect the tax amount that users manually adjusted on supplier bills. Before this change, the exported totals could still use the original tax value, which led to mismatches between the accounting report and the export file.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100086 Forward-Port-Of: odoo/enterprise#98684
This change prevents an access error that could block invoicing-only users from creating or opening invoices when a TDS/TCS warning is enabled. It allows the warning to work without requiring full accounting access, so business users can continue invoicing normally.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551 Forward-Port-Of: odoo/odoo#236965 Forward-Port-Of: odoo/odoo#236896
This update prevents hidden parts of a form from displaying the word “undefined” when they are not meant to be shown. It keeps those areas empty instead, which avoids confusing visual glitches in forms and button sections.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236724 Forward-Port-Of: odoo/odoo#236461
This update restores correct social media statistics by adapting to Facebook’s deprecated metrics. It keeps account and post reporting working even though some old data points were removed or renamed by Facebook, which helps prevent missing or incorrect trends in the dashboard.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
When an invoice is duplicated, it will no longer reuse the original sales order as its source document. This prevents copied invoices from showing misleading sales-order information and avoids errors in e-invoice exports that rely on that field.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656
12 changes
Enhancements to existing features
The system now checks whether a B2B buyer already exists in ECPay before sending the invoice, and creates the buyer automatically when needed. This helps avoid invoice submission failures in cases where the customer has not yet been registered on ECPay. The update also adds VAT validation support earlier in the process to catch incorrect VAT data before sending.
Original PR description
This commit aims to address an edge case where the buyer identifier might not exist on ECPay before issuing a B2B invoice. A call to "Add" a customer is made. RtnCode 1 indicates successful creation, 6160052 - indicates buyer already exists, others are failure. Additionally, add "base_vat" as dependency to enable client-sided validation for VAT before sending to ECPay. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236826
Resolved issues and error corrections
This update makes sure date placeholders in signing documents only appear for the signer they belong to. It prevents one signer from seeing the next signer’s placeholder, reducing confusion during the signing process.
Original PR description
Version: - saas-18.3 Steps to reproduce: - Add date fields for multiple signers. - When the first signer signs, the date placeholder for the next signer becomes visible to the first signer. Issue: - Date fields for next signers were showing placeholders to the current signer. Fix: - Added a condition to only set the placeholder when it has a valid value. Impact: - Ensures date placeholders are visible only to the correct signer. task-5218970
This change fixes an issue where the French balance sheet could become unbalanced after the 2024 chart of accounts update. It restores missing income and expense amounts in the retained earnings calculation so the report stays correct and consistent for 2025 reporting.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
This change prevents partner information from being unnecessarily recalculated on bank statement lines after an edit or deletion. It helps keep the correct partner on each line and avoids unexpected changes during reconciliation.
Original PR description
Before this commit, when having multiple lines in a statement line. By default, all the lines have a partner since we compute the partner depending of other lines. But in the case of an edit or a delete we don't want to recompute. What was happening is that the partner keep getting recomputed on the other lines even the one that was previously edited. This commit will add a context key when using the reconcile button to recompute the partners. opw-5179670
The OSS refresh action now correctly handles one company at a time instead of trying to run across all selected companies. This prevents an error when users work with multiple companies enabled and refresh the mapping on the active company.
Original PR description
To reproduce: - Activate multiple companies in the selector - Enable OSS on the active company - Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies. Forward-Port-Of: odoo/odoo#236103
Importing CSV files encoded in UTF-16 no longer fails with a low-level Python decoding error. Instead, users now get a clearer warning, making it easier to understand and fix file import issues.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266 Forward-Port-Of: odoo/odoo#226023
When a document is locked from the preview screen, the actions menu now updates immediately to show the correct options. This prevents users from seeing outdated actions and makes the document workflow more reliable.
Original PR description
Steps to reproduce =================== - Preview any documents. - Click on the actions menu and lock the document. - Now go to the actions menu again. => The set of options is not updated. Technical =========== - The action menu, which we are using inside the file previewer, is passed explicitly inside the FileViewer component of the document. We were using the `record.load()`, which will not have any effect on the FileViewer component and that's why the action menu was not updating. After this commit ================== - Used the `this._notifyChange()` method, which closes the preview and loads the model to align with the same behaviour as other actions. Task-4988116 Forward-Port-Of: odoo/enterprise#91760
The German DATEV export now uses the manually adjusted tax amount on vendor bills instead of an older calculated value. This ensures the exported accounting file matches what users see in the ledger and avoids reporting discrepancies.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100086 Forward-Port-Of: odoo/enterprise#98684
Invoicing-only users can now create and open invoices even when a TDS/TCS warning is present on the related account. This prevents access errors and avoids blocking normal billing work for users who do not have full accounting rights.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551 Forward-Port-Of: odoo/odoo#236965 Forward-Port-Of: odoo/odoo#236896
This change prevents a stray “undefined” label from appearing when parts of a form are hidden. It keeps the page clean and avoids confusing users, especially in larger forms where action buttons are loaded separately.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236724 Forward-Port-Of: odoo/odoo#236461
When an invoice is duplicated, it will no longer retain the original sales order as its source document. This prevents copied invoices from showing misleading links and avoids export or EDI issues caused by outdated source information.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656
This update fixes how Facebook statistics are calculated for connected accounts and posts after Facebook changed several reporting metrics. It helps keep the audience and post performance numbers working correctly, though one audience trend value is temporarily set to zero until a fuller fix is ready.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
4 changes
Resolved issues and error corrections
This update fixes an issue in the French accounting reports where the Balance Sheet could become unbalanced after the new 2024 chart of accounts was introduced. It ensures missing income and expense account balances are included correctly when calculating retained earnings, so the report stays accurate.
Original PR description
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA,…
[FIX] l10n_fr_reports: unbalanced Balance Sheet when coming from the 2024 CoA https://github.com/odoo/odoo/commit/8f3a86925e0301c15ca93b64d6237b69a534d71a introduced a new version of the French CoA, legally mandatory starting in 2025. Doing so, it also adapted the P&L and BS reports accordingly. However, it did not take into account the fact that some deprecated account codes would disappear from the P&L, causing the BS to be unbalanced when computing the retained earnings (by calling the P&L with a forced date_scope to run it on the full history). We fix that by reinjecting the balance of the missing Income and Expense accounts in the computation of the BS's Retained Earnings line. opw-5212801 =============================================================== [FIX] l10n_fr_reports : add new accounts in P&L Backport from https://github.com/odoo/enterprise/commit/eb35916f4f5a45e0c11919e0ee1a16e0caee010f , which was done in master for 18.2, but should have targetted older versions as well. Forward-Port-Of: odoo/enterprise#100116 Forward-Port-Of: odoo/enterprise#100077
This change corrects how the system reads responses from the Belgian BlackBox device when a message has to be retried. It prevents the software from misreading repeated replies, improving reliability of fiscal communication and reducing failed exchanges.
Original PR description
when sending NACK to the bb, it keeps replying but without starting by ACK. We the need to adapt to only parse ACK on the first time. Forward-Port-Of: odoo/enterprise#100002
The German Datev export now uses the manually adjusted tax amount when a bill’s tax total has been edited. This ensures the exported accounting data matches what users see in Odoo and prevents mismatches in reporting and tax files.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100086 Forward-Port-Of: odoo/enterprise#98684
This update restores accurate Facebook reporting after changes to Facebook’s statistics API. It updates how audience and post performance are calculated so the social dashboard keeps showing reliable numbers.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
4 changes
Resolved issues and error corrections
This fixes Balance Sheet report lines so they consistently apply the correct date scope when pulling figures from related reports. It helps ensure SYSCOHADA financial statements show accurate amounts for the selected reporting period.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
The Belgian Partner VAT Listing now excludes transactions marked as exempt based on the tax category code. This prevents exempt 0% taxes from being reported when they should not be, improving compliance and report accuracy.
Original PR description
Currently, the behavior is wrong and 0% taxes appear in the report (if the cumulative base for a partner is > 250) A distinction needs to be done here. The operations are taxable (even at a zero rate) or exempt. We shall rely on the Tax Category Code (E = Exempt) When a tax belongs to E, it cannot appear in the Partner VAT Listing. It is exempt from taxation. It does not open the right to deduction of vat on purchases. task-5269970 Forward-Port-Of: odoo/enterprise#99803
Pay run forms in some localizations include additional fields, but their values could be lost when the record was prepared for saving or display. This fix ensures those localized fields are kept, reducing the risk of missing payroll information.
Original PR description
In some localizations, extra fields are added in the form view of payruns, these field values are lost due to the way we buildRawRecord Forward-Port-Of: odoo/enterprise#100129
This fix updates Facebook social media statistics handling after Facebook deprecated some metrics. It prevents broken or unreliable stat calculations by removing unused data requests, using the replacement metric for post views, and temporarily setting uncertain audience trend values to zero until a fuller follow-up is available.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
22 changes
Enhancements to existing features
This change fills in missing inventory-related accounts and ensures every localization has the right default stock valuation setup. It helps companies avoid setup gaps when installing accounting or inventory features in different countries, so stock accounting works more reliably out of the box.
Original PR description
This PR 1. adds missing inventory management accounts in CoA 2. fills the default sotck valuation accounts in all l10n modules task-5176658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change reduces unnecessary live chat updates for people who are not actively viewing the relevant help section. As a result, Odoo sends fewer background messages, which improves performance and lowers noise without changing the user experience for those who open the live chat area.
Original PR description
Before this commit, every live chat user would receive looking for help update. This commit reduces the dispatching of message by targeting users interessted in the looking for help update. The looking for help category is folded by default, in which case the user doesn't receive anything related to live chats looking for help. Once the user accesses discuss, and once the category is opened, updates will be received. 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
The system now waits longer between homepage data refreshes when a tab stays open, instead of repeatedly requesting updates. This helps reduce unnecessary load on the IoT Box and improves stability over time.
Original PR description
In order to avoid spamming the IoT Box with requests to update the homepage when a tab is kept open, we now progressively delay the `/data` fetch during the first 30min to end up fetching only once every 30min. Forward-Port-Of: odoo/odoo#236664
This update makes sure a buyer record is created on ECPay before sending a B2B invoice, reducing the chance of invoice submission failures when the buyer is not yet known to the service. It also adds VAT validation support earlier in the process, helping catch invalid VAT data before it is sent.
Original PR description
This commit aims to address an edge case where the buyer identifier might not exist on ECPay before issuing a B2B invoice. A call to "Add" a customer is made. RtnCode 1 indicates successful creation, 6160052 - indicates buyer already exists, others are failure. Additionally, add "base_vat" as dependency to enable client-sided validation for VAT before sending to ECPay. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236826
The Japanese state and prefecture records have been updated to use their native Japanese names instead of relying on translations. This makes location data display more consistently for Japanese users and improves the accuracy of standardized state codes.
Original PR description
Since state names are not handled by translations, storing them directly in Japanese provides a better user experience. This **PR** updates the existing Japanese state records with their native Japanese names. Additionally, it aligns the state codes as per ISO standards. **task**-5345872 Forward-Port-Of: odoo/odoo#236649
Resolved issues and error corrections
This update adds the missing date filters to certain Balance Sheet lines so they behave correctly when users compare or analyze different reporting periods. It helps ensure the report shows the right figures for the selected dates and avoids confusing results.
Original PR description
Forward-Port-Of: odoo/enterprise#99889
This update corrects how browser platform information is simulated in mail-related automated tests. It helps ensure the tests reflect real user environments more accurately, reducing the risk of false test results and improving reliability.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac",
"windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be
added to the user agent string.
This commit adapts its usage(s) accordingly.
Forward-Port-Of: odoo/odoo#236837This update corrects the vendor on-time rate shown in Purchase reporting so it matches the graph and the actual purchase order quantity. It prevents duplicate or adjusted receipts from artificially lowering the rate, giving businesses a more accurate view of supplier performance.
Original PR description
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to…
**Steps to reproduce:** 1- Install the purchase_stock module. 2- Create a new PO with a new vendor. 3- Add new one product in the purchase order line with quantity > 1. 4- Confirm the PO and go to the generated receipt. 5- Validate the receipt with less than the ordered quantity, by choosing no backorder. 6- Duplicate the receipt for the remaining quantity and validate it. 7- In vendor form view, the On-time Rate value shown in the smart button differs from the value in the graph. **Issue:** https://github.com/odoo/odoo/blob/e7da32fe67cfe78bc6da8bf5d36a7c584763e3bb/addons/purchase_stock/report/vendor_delay_report.py#L26-L42 - The On-time Rate shown in the smart button does not match the graph. **Example:** - PO Line ordered qty: 10 - First receipt validated: 6 (no backorder) - Duplicated receipt validated: 4 - In vendor form view inside On-time Rate Smart button - Total quantity coming: 14 (incorrect) - Expected total qty for calculation: 10 (from PO line) - On-time delivery rate calculated: **71.43%** - Expected On-time delivery rate: **100%** **Cause:** - The report uses `product_qty` from the stock move. - When a receipt is duplicated and the demand quantity is manually set, `product_qty` is recomputed from this demand value. This leads to a mismatch between the PO line quantity and the aggregated stock move quantities. **NOTE:** In `test_02_vendor_delay_report_partially_cancelled_purchase_order`, added the line:: `purchase_order.order_line.flush_recordset()` - Because we were taking the `partner_id` from the `Purchase Order line` is a stored related field. - The computed value first lives in Odoo’s cache. - It is not written to the database until a flush occurs. - If we immediately call something like _read_group() (which queries the database directly), it won’t see the cached value — only what is persisted in the DB. **Solution:** - Use the purchase order line quantity instead of the stock move’s `product_qty` to ensure consistent and accurate On-time Rate calculation. opw-4991367 Forward-Port-Of: odoo/odoo#236779 Forward-Port-Of: odoo/odoo#225529
This fix updates partner records when certain e-invoicing modules are removed, so the system no longer crashes when opening a partner that was using one of those formats. It improves stability during module uninstall and avoids unexpected tracebacks for users.
Original PR description
Before this fix, if you uninstalled this module and navigated to any partner that had a e-invoice format defined by this module, you'd have a traceback. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr @moduon MT-12168 OPW-5172861 Forward-Port-Of: odoo/odoo#235301 Forward-Port-Of: odoo/odoo#232297
This update corrects how the VoIP softphone tests simulate different devices and browsers. It helps ensure the tests behave as intended, improving reliability of future VoIP updates.
Original PR description
The `mockUserAgent()` is meant to be used with a "platform" ("mac", "windows", "android"...) as parameter and not a whole user agent string.
In specific cases, a custom string can be used instead, but only to be added to the user agent string.
This commit adapts its usage(s) accordingly.This update fixes a broken Mexican trial balance test so it matches the current chart of accounts. It also renames some UK report methods to avoid conflicts with existing UK module behavior, helping keep report functionality stable.
Original PR description
This commit fixes the Mexican trial balance unit test that was broken due to newly added accounts in Mexican CoA. It also renames methods from _get_uk_... to _get_uk_reports_... in l10n_uk_reports_cis to avoid overriding the methods in l10n_uk module. task-5176658
This update fixes how default due dates are set for several local report templates. It ensures the system uses the correct company-specific default values, reducing the risk of inconsistent reporting settings across countries.
Original PR description
The fields default_deadline_periodicity and default_deadline_days_delay have been added on the return type model because they handle the company dependant property of their associated field, and they are the ones that should be used in the xml.
This fix prevents website pages from breaking when a dynamic snippet still points to a deleted filter after an app is removed and reinstalled. It restores the previous behavior by checking that the filter exists before trying to render it, which keeps the editor and homepage working normally.
Original PR description
**Patch description:** - Following commit: odoo/odoo@e3b062e5d3820ddfcee2eb669f21edc0c53c3330 the behavior of dynamic snippet rendering changed. - Previously (up to v18.4), the system first checked…
**Patch description:**
- Following commit: odoo/odoo@e3b062e5d3820ddfcee2eb669f21edc0c53c3330 the behavior of dynamic snippet rendering changed.
- Previously (up to v18.4), the system first checked whether the dynamic filter existed before calling `_render` on it. After the referenced commit, `get_dynamic_filter` attempts to find the filter and immediately calls `_render`, even if the filter record is missing. diff: https://github.com/odoo/odoo/commit/e3b062e5d3820ddfcee2eb669f21edc0c53c3330#diff-d41b2dc5ff6fd6a303373f86e1af97d055db315ccc431749b4ffac1488dea119R416-R423
**Steps to reproduce:**
- Create a v19 db and install `website_sale`
- Add a dynamic snippet (e.g., Product Catalog) to the website homepage.
- Uninstall `website_sale`
- Install `website_sale` again
- Open the website homepage and then editor
- Traceback:
```py
File "/home/odoo/odoo/odoo/addons/website/controllers/main.py", line 424, in get_dynamic_filter
return dynamic_filter_sudo._render(**kwargs) or []
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website/models/website_snippet_filter.py", line 78, in _render
records = self._prepare_sample(limit, res_model=res_model)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website/models/website_snippet_filter.py", line 183, in _prepare_sample
records = self._prepare_sample_records(length, **options)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/addons/website/models/website_snippet_filter.py", line 201, in _prepare_sample_records
model = self.env[(self.model_name or options.get('res_model'))]
~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/odoo/orm/environments.py", line 107, in __getitem__
return self.registry[model_name](self, (), ())
~~~~~~~~~~~~~^^^^^^^^^^^^
File "/home/odoo/odoo/odoo/odoo/orm/registry.py", line 322, in __getitem__
return self.models[model_name]
~~~~~~~~~~~^^^^^^^^^^^^
KeyError: None
```
The issue occurs because the snippet’s `data-filter-id` refers to a filter record that gets deleted when `website_sale` is uninstalled. Upon reinstalling, new filter records are created with new IDs. The old snippet still references the deleted ID,
so in `get_dynamic_filter` when searching with `filter_id` returns no record.
Despite `_render` having an `self.ensure_one()` check, the mentioned commit changed it to `self and self.ensure_one()`, allowing a null/empty recordset to pass through and causing rendering issues.
This fix restores the proper behavior by verifying the filter’s existence before rendering.
opw - 5163214, 5248474
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update prevents checkout from crashing when Authorize.net returns an unexpected error. Instead of a technical failure, the payment is now marked as failed and the customer sees the error message, making the issue easier to understand and handle.
Original PR description
Currently an error occurs when a user tries to pay using Authorize.net, and Authorize.net returns an error in the response. **Steps to replicate:** * Install `website_sale` and `payment_authorize`…
Currently an error occurs when a user tries to pay using Authorize.net, and Authorize.net returns an error in the response. **Steps to replicate:** * Install `website_sale` and `payment_authorize` with demo. * Setup the payment provider Authorize.net with valid credentials. * Add the product to your cart, proceed to checkout, then use and save the payment details from [1] and complete the purchase. * Repeat the checkout process after replacing the `API Login ID` with an invalid value, and then pay using the saved payment details. **Error:** `TypeError: float() argument must be a string or a real number, not 'NoneType'` **Root cause:** * The error happens because after the API request at [2], an error response causes `tx_details` to have no `transaction` key, as shown in [3]. This makes the amount at [4] become `None`, which then triggers an error at [5] when Python tries to convert `None` to `float`. * As noted in the Authorize.net forums (see [6], [7], [8], [9]), the `E00040 'record not found'` error can appear when Authorize.net has synchronization issues on their end. **Solution:** * Show the error, change the transaction’s status to ‘error’, and save the error message on the transaction. [1]: https://developer.mastercard.com/unified-checkout-solutions/documentation/testing/test_data/ [2]: https://github.com/odoo/odoo/blob/f272eb19813be4254fd461ec21f1cc47e8834559/addons/payment_authorize/models/payment_transaction.py#L160 [3]: https://drive.google.com/file/d/1JrXkKzRRTbpjZ8l0kJsX5SIg-kS-P5tv/view?usp=sharing [4]: https://github.com/odoo/odoo/blob/f272eb19813be4254fd461ec21f1cc47e8834559/addons/payment_authorize/models/payment_transaction.py#L163 [5]: https://github.com/odoo/odoo/blob/f272eb19813be4254fd461ec21f1cc47e8834559/addons/payment_authorize/models/payment_transaction.py#L167 [6]: https://community.developer.cybersource.com/t5/Integration-and-Testing/E00040-The-record-cannot-be-found-right-after-profile-create/m-p/55106#M30039 [7]: https://community.developer.cybersource.com/t5/Integration-and-Testing/E00040-when-Creating-Subscription-from-Customer-Profile/m-p/59597#M34176 [8]: https://stackoverflow.com/questions/67506179/authorize-net-shows-e00040-when-creating-subscription-from-customer-profile [9]: https://community.developer.cybersource.com/t5/Integration-and-Testing/quot-E00040-The-record-cannot-be-found-quot-when-creating/td-p/62409 sentry-7021997195
This fix ensures any extra fields added to payroll run forms by local customizations are kept when the record is saved. It prevents users from losing entered information in localized setups, improving reliability for payroll processing.
Original PR description
In some localizations, extra fields are added in the form view of payruns, these field values are lost due to the way we buildRawRecord Forward-Port-Of: odoo/enterprise#100129
The website event editor now correctly reads the event ID from event page URLs, even when the event title contains characters that are encoded in the web address. This prevents the wrong event from being selected during editing for internationalized event titles.
Original PR description
The website event page extracts the event id from urls that are formatted like "/event/[title]-[id]/" by matching the first number not followed by a word character. Languages like Korean however will have their title percent-encoded like "%EC%82%AC%EC", causing the regex to miss the true ID and return the wrong one. Steps to Reproduce: 1. Create an event with a Korean title eg "모든 행사". 2. Go to the website view and click on edit. 3. You'll see that the regex grabs a wrong id. This fix is for adapting this commit https://github.com/odoo/odoo/commit/d16b0a8e303047997a0d4764f55bb7f1c214d47b to the use of plugins over snippets in 18.4 and onwards. opw-5095411 Forward-Port-Of: odoo/odoo#232781
When an invoice is duplicated, it will no longer keep the original sales order as its source document. This prevents misleading information on copied invoices and avoids incorrect data being sent to external e-invoicing systems.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656
This update fixes how Facebook statistics are calculated for connected accounts and posts after Facebook changed some of its metrics. It helps keep social performance numbers accurate by switching to supported data sources and temporarily neutralizing one trend measure until a fuller fix is available.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119
This update fixes the German DATEV export so it reflects manual changes made to a bill’s tax amount. This ensures the exported accounting file matches what users see in the ledger and avoids reporting discrepancies.
Original PR description
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting /…
- Install Accounting and `l10n_de_reports` - Switch to a German company - Create a bill: * Price: `100.00` * Taxes: `19%` - Edit the tax total with the pencil button - Go to "Accounting / Reporting / Audit Reports / General Ledger" => The tax amount is the one that has been edited manually - Download `Datev DATA (zip)` - Open `EXTF_accounting_entries.csv` file The total amount in the file is the one before the edition of the tax amount. The Datev data depends on `price_total` field of the invoice lines, but this field is not updated when the tax amount is edited manually. We now check the total by adding `price_total` of each invoice line and the total amount defined in `tax_totals` field. If there is a difference, compute the delta for each tax group and split it between all the lines where a tax of that group is used. Ticket [link](https://www.odoo.com/odoo/project.task/4951488) opw-4951488 Forward-Port-Of: odoo/enterprise#100086 Forward-Port-Of: odoo/enterprise#98684
Importing CSV files encoded in UTF-16 now fails with a clear warning instead of a low-level error. This makes bank transaction imports easier to diagnose and helps users correct file encoding issues faster.
Original PR description
Currently, an error occurs when importing CSV files encoded in utf-16. **Steps to reproduce:** - Install the `account_bank_statement_import_csv` module. - Open invoicing and upload file [1] in Bank transactions. - Change the encoding to `utf-16` and click `test`. **Error:** `UnicodeDecodeError: 'utf-16-le' codec can't decode byte 0x0a in position 376: truncated data` **Root Cause:** At [2], the CSV data is decoded strictly with the specified encoding. When decoding detects incomplete or unexpected byte sequences, Python raises an `error`. **Fix:** This commit ensures raising a `warning`, improving the `error message clarity`. [1]: https://drive.google.com/file/d/14thHRN210aeY8fcUBAb01PniVrd7QHer/view?usp=sharing [2]: https://github.com/odoo/odoo/blob/67503c0ce7ede8373800caa0a12203d271b7f1ae/addons/base_import/models/base_import.py#L544 sentry-6864546266 Forward-Port-Of: odoo/odoo#226023
This change prevents access errors when users with invoicing-only permissions create or open invoices linked to TDS/TCS settings. It ensures the warning shown for Indian withholding rules is available without requiring full Accounting access, so day-to-day invoicing continues smoothly.
Original PR description
Invoicing users were unable to create or open invoices because the `l10n_in.section.alert` model (used for TDS/TCS warning on the chart of account) was restricted only to Accounting groups (Administrator and Read-only). **Steps to Reproduce** 1. Install l10n_in,account_accountant 2. Create two users: - Admin user - Invoicing user (only invoicing rights) 3. As Admin: - Enable TDS/TCS module - Open any Chart of Account - Select a TDS/TCS Section - Save 4. As Invoicing user: - Try to create an Invoice/Bill with that Chart of Account → Access Error occurs Fix Result Invoicing-only users can now create and access invoices without access errors. Task-5346551 Forward-Port-Of: odoo/odoo#236965 Forward-Port-Of: odoo/odoo#236896
This update prevents the word “undefined” from appearing when parts of a form are hidden during page rendering. It improves the display of full-size forms, especially where action buttons are prepared separately, so users see a clean empty area instead of confusing text.
Original PR description
Currently if the root node of a template is invisible at compile time the "new root" will contain the word "undefined" in plain text. Instead if we skip rendering the root for whatever reason, the new root should simply be an empty t node. This lead to issues in full-size forms specifically as the controller compiles the buttons separately. Meaning if the buttons div was evaluated to be invisible for whatever reason you would get "undefined" where stats buttons normally go. task-5322823 Forward-Port-Of: odoo/odoo#236724 Forward-Port-Of: odoo/odoo#236461
4 changes
Enhancements to existing features
This update stores Japanese state names directly in Japanese instead of relying on translation. It also aligns state codes with ISO standards, improving consistency and making addresses clearer for users in Japan.
Original PR description
Since state names are not handled by translations, storing them directly in Japanese provides a better user experience. This **PR** updates the existing Japanese state records with their native Japanese names. Additionally, it aligns the state codes as per ISO standards. **task**-5345872 Forward-Port-Of: odoo/odoo#236649
Resolved issues and error corrections
This update corrects how the POS black box reads responses after a retry. It now handles repeated replies properly, which helps prevent errors when a device does not restart its message the same way on subsequent attempts.
Original PR description
when sending NACK to the bb, it keeps replying but without starting by ACK. We the need to adapt to only parse ACK on the first time.
This change fixes an error that could occur when refreshing OSS mapping while multiple companies were active. The system now handles the action correctly for the selected company, preventing the crash and letting users continue their work normally.
Original PR description
To reproduce: - Activate multiple companies in the selector - Enable OSS on the active company - Click the refresh mapping button ===> Traceback, because a function expects to be called on a single company and is instead called on all the active companies. Forward-Port-Of: odoo/odoo#236103
When a customer invoice is duplicated, it will no longer keep the original sales order as its source document. This avoids incorrect information being shown on copied invoices and prevents external reporting or electronic invoicing systems from using outdated source data.
Original PR description
Currently we copy the `invoice_origin` field on moves (when copying / duplicating moves). I.e. when copying a move that was created from a SO we end up with the `invoice_origin` filled on the copied move (but the SO is not linked and does not really have anything to do with the move anymore) This can i.e. lead to issues in EDIs (`l10n_es_edi_verifactu` like in the ticket) that send the `invoice_origin` as part of the data about the move. Reproduce 1. Create a sales order (SO). 2. Create an invoice from the SO (and confirm). You can see that the SO is linked at the top (smart button). 3. Copy the invoice (and confirm). You can see that the SO is not linked. 4. Go to the invoices list view and make the "Source Document" visible. 5. Both the invoices have the same SO as their "Source Document". opw-5115495 Forward-Port-Of: odoo/odoo#236656
1 change
Resolved issues and error corrections
This update corrects how Facebook statistics are computed for connected social accounts and posts. It addresses Facebook’s deprecation of older metrics so the reported audience and post activity data stays accurate and avoids broken stats.
Original PR description
Bug === Facebook deprecated some of the endpoints related to statistics https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics For the accounts, `page_fan_adds` and `page_fan_removes`, we are still unsure about unfollow, and so to get a fix quickly, we set the audience trend to zero, and we will fix it later. For live post, we used `post_impressions` in the API call, but that metric was not used, so we just remove it. For stream post, `post_impressions` has been replaced by `post_media_view`, as suggested in the migration note from Facebook. Task-5346965 Forward-Port-Of: odoo/enterprise#100119