Thursday, March 12, 2026
34 changes · 19.0
New functionality added to Odoo
This update incorporates the National Bank of Georgia (NBG) as a source for automatic currency rates, ensuring compliance with Georgian tax regulations. It translates transactions into Georgian Lari (GEL) using the official NBG exchange rate, which is now automatically updated. This ensures accurate financial reporting for transactions in Georgia.
Original PR description
This commit adds the National Bank of Georgia (NBG) as a supported service provider for automatic currency rate updates. Purpose: To comply with the Georgian Tax Code (Article 73), taxable transactions must be translated into the national currency (GEL) using the official exchange rate defined by the NBG for the transaction day. Functionality: -Enables fetching official exchange rates directly from NBG. -Automatically handles rates defined for different quantities (e.g, rates quoted per 100 units instead of 1 unit). task-5894623
Enhancements to existing features
The accounting account list can now show description and company information as optional columns. This gives users more context when reviewing accounts while keeping the default view uncluttered.
Original PR description
This commit will add the description field in optional hide in the view of account_account. task-5493859 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Restaurant point-of-sale orders now update their displayed name when the customer is changed, as long as the previous name came from the former customer. This avoids confusing order labels in delivery or eat-in flows and helps staff identify the correct customer order.
Original PR description
When a partner is changed on an order that was previously named after another partner (e.g. in a Delivery/Eat In preset scenario), the order name was not updated. This was because once `floating_order_name` is set, the order is no longer considered a "direct sale", and the logic to update the name from the partner was bypassed. This commit updates `setPartner` to check if the current name matches the name of the previous partner. If so, it updates the name to the new partner's name. task-id: 6000287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Documentation and clarification updates
This pull request records that contributor ahmedoosama has signed Odoo's Contributor License Agreement. This is an administrative legal update that helps ensure contributions can be accepted under the project's licensing rules.
Original PR description
CLA signature for ahmedoosama --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Indian localization demo data now includes PAN entities connected to supplier demo partners with MSME type and MSME number details. This helps users and implementers see how MSME reporting works with realistic supplier examples during demonstrations or testing.
Original PR description
- Introduce demo PAN entities linked to suppliers with MSME type and MSME number for demo partners. Ent PR: https://github.com/odoo/enterprise/pull/94047 task-4140405
This update enhances the statement line dropdowns by adding colored bubbles to highlight related move lines with matching amounts (currency or amount). This provides a visual cue for users, streamlining reconciliation efforts and reducing potential errors. The feature also includes an optional display setting for increased flexibility.
Original PR description
This will add a new colored bubble on the dropdown of a statement line when there is a move line that has the same amount currency or amount. task-5493859
Cancelled stock movements are no longer included when calculating the cost of goods sold for kit products. This helps ensure financial reporting reflects only completed activity and avoids overstating or misstating kit costs.
Original PR description
Currently cancelled moves are also being used when getting the value. This is already done in the main method: https://github.com/odoo/odoo/blob/049321aa5e0d4271050b406477bac5fb788b410b/addons/stock_account/models/account_move_line.py#L67 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now remove the company from an expense without triggering an error. This keeps expense editing smoother in multi-company setups and avoids disruption during data entry.
Original PR description
Currently an error occurs when user tries to remove company on an expense. Steps to replicate: - Install `hr_expense` and create a new company. (make sure you have more than one company). - Create new expense and remove the value from company field. Error: `ValueError: Compute method failed to assign hr.expense(<NewId origin=7>,).is_editable` Cause: - Removing the company triggers the [compute] that skips the loop if company is not assigned [1], which causes this error. Solution: - Assign `is_editable` as False when company is false. [compute]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L304-L363 [1]: https://github.com/odoo/odoo/blob/43505c919e29065b04d4e9e0a66f38a13f42daed/addons/hr_expense/models/hr_expense.py#L326-L331 No ID --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241507
Point of Sale receipts now keep company phone numbers readable when the receipt language is Arabic or another right-to-left language. This prevents phone numbers from appearing in the wrong order, reducing confusion for customers and cashiers.
Original PR description
# Steps to reproduce: - Open the company, change the language to Arabic - Go to POS, open the shop - Buy anything and click on receipt # Problem: When clicking on the receipt, you would find the…
# Steps to reproduce:
- Open the company, change the language to Arabic
- Go to POS, open the shop
- Buy anything and click on receipt
# Problem:
When clicking on the receipt, you would find the phone number is written right to left, although it should be printed left to right.
# Cause:
Normally when another language is selected, this line will adapt to it, and translate the whole block "Tel: `props.data.company.phone`" to arabic (right to left)
https://github.com/odoo/odoo/blob/5fc1e34d174f7f61d692d086d0ff65fbfc72b013/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L12
# Fix:
We need to specify the direction of the phone number to be Left to right.
```
<div>Tel:<span dir="ltr"><t t-esc="props.data.company.phone" /></span></div>
```
**Result:**
<img width="167" height="86" alt="HATEF" src="https://github.com/user-attachments/assets/4fe0bdd0-fe77-430f-9136-cd7086c4d5d9" />
There is also alternative fixes:
# First alternative fix:
Replace the '+' with '00' (there is no difference when trying to copy), and make a function in js that preserve the whole thing in a string variable.
```
get phoneText() {
return _t("Tel:") + " " + this.props.data.company.phone.replace("+", "00");
}
```
**Result:**
<img width="215" height="148" alt="hatef2" src="https://github.com/user-attachments/assets/e9cb4415-baad-4d66-a04b-ecdb308e3e72" />
**Drawback:**
- The inconsistency between how the number is stored and how we view it.
# Second alternative fix:
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.js`
```diff
import { _t } from "@web/core/l10n/translation";
import { Component } from "@odoo/owl";
+ import { localization } from "@web/core/l10n/localization";
```
```diff
+ get direction() {
+ return localization.direction;
+ }
```
**File:** `/home/odoo/codebase/odoo/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml`
```diff
<t t-if="props.data.company.phone">
- <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ <t t-if="direction == 'ltr'">
+ <div>Tel:<t t-esc="props.data.company.phone" /></div>
+ </t>
+ <t t-elif="direction == 'rtl'">
+ <div><t t-esc="props.data.company.phone" />Tel:</div>
</t>
</t>
```
**Drawback:**
- Too much code for a small issue that probably won't bother the client.
- The need to change in multiple translation files for all RTL languages in odoo.
- Readability
opw-5881503
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#252348
Forward-Port-Of: odoo/odoo#249060The stock transfer error now identifies the specific package causing a consistency issue. This helps users working with large transfers find and correct the problem faster without support assistance.
Original PR description
The current error does not specify which package is problematic. This cause issues on big transfers with many products / packages. Specifying the package in the error helps the customer identify the issue, and correct it themselves. OPW-5923839 --- <img width="673" height="252" alt="image" src="https://github.com/user-attachments/assets/0ccb45be-d813-4933-86fd-0dd3506d2775" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252351 Forward-Port-Of: odoo/odoo#249290
This fix prevents non-website editors from using the default language of the first website when displaying view content. It keeps website-specific translation behavior limited to the Website HTML/CSS editor, reducing confusion when users edit reports or other views in Studio.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. This is done here by adding a context flag, as to not interfere with customizations made in stable versions. This will be changed for master. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/odoo#250950 Forward-Port-Of: odoo/odoo#237000
Point of Sale invoices are no longer rounded in cases where rounding is not required. This prevents small, unnecessary invoice amount changes and helps keep customer billing accurate.
Original PR description
Backport of https://github.com/odoo/odoo/pull/247223. opw-5890586 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251104 Forward-Port-Of: odoo/odoo#249834
Online store filter controls now keep “View more” and “View less” translated when shoppers browse in languages other than English. This improves the shopping experience for multilingual websites by avoiding unexpected English text in product filters.
Original PR description
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to…
When browsing an eCommerce in any language but English and trying to filter on an attribute with more than 8 values and at most 20, the "View more" and "View less" options are not translated Steps to reproduce: 1. Install eCommerce 2. Create a product with one attribute that has 9 to 20 values and publish the product to the eCommerce (the attribute should have radio display type and should be visible in the eCommerce) 3. Add a language (e.g. French) and translate the eCommerce's website 4. Open the website and set the language to French 5. In the left column, open the filter for the attribute previously created 6. Click on "Voir plus" 7. "View less" is not translated, if you click on it, "View more" is not translated anymore Issue: The translation for "View more" is generated because it is present in the template `filter_radio_and_multi_attributes` but when we update the text in website_sale.js, the terms are not translated anymore Solution: Use `_t` to translate the "View more" and "View less" terms opw-5985712
This fixes an issue in the website editor where users could add a file block but could not remove it using Backspace. File attachments placed in editable content now behave as expected, reducing editing friction and preventing stuck content blocks.
Original PR description
Steps to reproduce: =================== 1- Go to website & add a file using /file or /upload file 2- Click on the file box and press backspace -> Nothing happens. Cause: ====== After this commit [1], `is_node_editable_predicates` was added to prevent color from being applied to the file box so when removing the file box, The delete plugin's removeNode checks `isNodeEditable(node)` which returns false for the file box and thus prevents it from being removed. Solution: ========= a non-editable node that sits inside an editable parent should still be removable so now : node is not removable if !isNodeEditable(node) & its parent is also not contentEditable [1]: https://github.com/odoo/odoo/pull/226927/changes/7f4eedd76c833f3a162070563f3982a1fbdb77c7 opw-5995236 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Back-in-stock notification emails now display product images at an appropriate size instead of showing oversized full-size images. This improves the appearance and readability of customer notification emails.
Original PR description
Steps to reproduce in local: 1. Install `website_sale_stock` 2. Make a product variant with an image 3. To make it easy set field `Back in stock Notifications`'s value on this product with the help…
Steps to reproduce in local:
1. Install `website_sale_stock`
2. Make a product variant with an image
3. To make it easy set field `Back in stock Notifications`'s value on this product with the help of the studio
4. Add a person to receive notification in this field
5. Don't set Outgoing email server
6. Run cron `Product: send email regarding products availability` manually
7. To Check sent email go to `Setting > Technical > Email > Emails`
Issue:
- The image is a full-size image
<table>
<tr>
<th style="text-align: center;">Before</th>
<th style="text-align: center;">After</th>
</tr>
<tr>
<td style="text-align: center;">
<img width="1395" height="728" alt="Before"
src="https://github.com/user-attachments/assets/a3fe3b38-c4a5-4a78-a63a-552c96cfdf84" />
</td>
<td style="text-align: center;">
<img width="1383" height="662" alt="After"
src="https://github.com/user-attachments/assets/8c346302-4295-44f2-8172-6a01072b23c7" />
</td>
</tr>
</table>
opw-5915587
Forward-Port-Of: odoo/odoo#249000Odoo now avoids repeatedly clearing Python's warning tracking when using its bundled URL handling code. This reduces unnecessary repeated warning messages in busy deployments, making logs cleaner and easier to monitor without changing user-facing features.
Original PR description
Every manipulation of the warnings list flushes the warnings registry, which prevents `warnings.warn` from deduplicating `default`, `module`, and `once` actions, instead they all behave as if `always`. Because werkzeug.urls is used *a lot* in odoo, this causes warnings to be emitted continuously even if that's not intentional, something which is already an issue due to workers (every new worker has an empty warnings registry triggering duplicate warnings). Upstream fixed this issue in pallets/werkzeug#2692 which was merged in 2.3.4, but apparently we vendored 2.3.0 which didn't have these fixes. Forward-Port-Of: odoo/odoo#252427 Forward-Port-Of: odoo/odoo#252193
This update adds the required Danish identifier label to buyer information in Nemhandel invoices. It helps ensure generated OIOUBL documents meet Danish formatting requirements and are accepted by receiving systems.
Original PR description
Nemhandel follows the OIOUBL 2.1 XML format. To specify the Buyer identifier, we use the <cac:PartyIdentification> node. But we are missing the `schemeID` attribute, which should be for DK "DK:CVR". This commit adds this attribute. opw-5232123 Forward-Port-Of: odoo/odoo#253132 Forward-Port-Of: odoo/odoo#250942
This fixes a visual issue where the mobile mega menu back arrow could appear with the wrong font after changing the website navigation font. Visitors using mobile navigation will now see the expected back icon consistently.
Original PR description
Steps to reproduce: =================== 1. Go to webstie and add a mega menu 2. Change Navbar font (e.g. to "Arvo") 3. Switch to mobile view and open the mega menu -> the back arrow will have unexpected style. Cause: ====== The selector `.navbar .nav-link` applies the custom navbar font-family (e.g., "Arvo") to all `.nav-link` elements inside the navbar. The mega menu back button has classes `btn nav-link oi oi-chevron-left`, so it matches this selector. Since `.navbar .nav-link` has higher specificity than the base `.oi` class, the custom font overrides `font-family: 'odoo_ui_icons'`. Solution: ========= force the .oi font-family. opw-5949405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251394
This fix keeps popup display settings in sync when website editing history is replayed. It prevents popups from unexpectedly appearing or disappearing while users undo or redo website builder changes.
Original PR description
The attribute change processor supposed to avoid changing the `display` property of the `style` attribute of the popup element when an history step is replayed (added in cce4527c85e3240ff50fa573b141bc5973a46c2e) was mistakenly using the old display value from the history instead of the current value of the target. This was usually not an issue because in the cases where those value differed, the popup was about to be revealed (or hidden) anyway to show the target at that history step. This commit keeps the value of the property `display` of the `style` attribute as it is currently on the target, instead of the value of what it should have been as registered by the history. task-5149984 Forward-Port-Of: odoo/odoo#253106
This fix prevents custom field tracking data from growing unnecessarily during database upgrades. It helps keep upgrades stable and avoids extra memory use caused by duplicated internal field records.
Original PR description
During upgrades we observed an uncontrolled growth of the mappings `field_depends` and `field_depends_context` in the registry. The Field instances that serve as keys are duplicated for custom models. This comes from the fact that custom models are completely reloaded during registry setup, even incremental setup. To avoid duplication we consider custom models to be re-setup, which they actually are.
Co-authored-by: Raphael Collet <rco@odoo.com>
Co-authored-by: Xavier Dollé (xdo) <xdo@odoo.com>This fixes how Romanian e-invoices identify CPV classifications by using the officially required code value. It helps prevent validation or compliance issues when exchanging invoices through Peppol-compatible systems.
Original PR description
The value of `ItemClassificationCode/listID` that corresponds to `CPV` classification is `STI` not `CPV`. See https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ task-5416833 Forward-Port-Of: odoo/odoo#251311 Forward-Port-Of: odoo/odoo#250045
This update resolves an issue that prevented the generation of Customer Statement reports. The problem stemmed from a missing domain variable, causing an error during report processing. The fix ensures the domain is always provided, allowing reports to generate successfully.
Original PR description
**Steps to reproduce:** * Install the **l10n_my_reports** module. * Go to `Accounting > Reporting > Partner Ledger`. * Change report to `Customer Statement`. * Add data in the report and click Send. * In the email template, set the `dynamic reports` as `statement of accounts` under the options tab. * Click Preview. **Observed behavior:** * Error: `TypeError: Domain() invalid argument type for domain: None` * Email preview fails and PDF cannot be generated. **Cause:** * The `statement_account_document` template uses `filtered_domain(domain)` but the domain variable was not being passed to the template context by the `_get_report_values` method, resulting in None being passed to `filtered_domain()`. **Fix:** * Ensure domain is always present in the report context, defaulting to an empty list when not provided. * Added safe handling for missing data and context parameters. opw-5880385
This update corrects a bug where users without HR document centralization enabled were seeing all documents, not just their own employee documents, when using the documents smart button. The fix restores the intended behavior for companies without this HR setting, ensuring employees only access their own related documents.
Original PR description
Steps: - uncheck the "Human Resources" file centralization option - go to an employee, click the documents smart button -> You see every documents, not only the ones from the employee PR https://github.com/odoo/enterprise/pull/93782 aimed at restoring the previous behaviour of the employee documents button and accesses for companies without the hr documents settings enabled, but forgot the domain on the employee smartbutton action. opw-5857914 Forward-Port-Of: odoo/enterprise#107224
This update ensures that Website Studio only uses translations relevant to the currently selected website when editing views. Previously, it defaulted to the first website's language, causing potential inconsistencies. This change improves the accuracy of translations within the Studio interface, specifically for the HTML/CSS Editor.
Original PR description
Problem: When opening the Studio XML editor when Website is installed, the translation terms corresponding to the Default Language of the first website in the database are used. This behavior should only be applied to the HTML/CSS Editor in Website. Purpose: Modify Website's override of get_related_views to only return translated views when called with a specific website in context. Steps to Reproduce in Runbot: 1. Activate a non-English (US) language. 2. Add this language to the Website with the lowest ID in the database, then set it to the Default Language of the Website. 3. Enter Studio and navigate to a view that has translation terms in its view (ex. Invoice PDF Report), then open the XML editor. opw-5136124 Forward-Port-Of: odoo/enterprise#108902 Forward-Port-Of: odoo/enterprise#107459
This update resolves intermittent test failures in the sign functionality by using dedicated test users instead of the default 'admin' and 'demo' accounts. This ensures consistent and reliable test results, improving the overall stability of the sign process. The change focuses on deterministic test execution.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216
A test was failing due to an issue with how the system handles time zones. The fix corrects a calculation error that resulted in an incorrect date being generated, specifically when the system's time zone is set differently from the test environment. This ensures the test consistently passes.
Original PR description
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ##…
__ ## Error description The test fails when it is launched at 23h. We obtain an assertion error: `AssertionError: datetime.datetime(2026, 2, 26, 11, 0) != datetime.datetime(2026, 2, 25, 11, 0)` ## Origin of the issue In the `_default_start_datetime()` method of planning, we return `return datetime.combine(fields.Date.context_today(self), time.min)`. So, we call context_today. which is implemented this way: https://github.com/odoo/odoo/blob/f3ec2aa4514c03874aae96ae975e2617e8260c72/odoo/orm/fields_temporal.py#L154-L158 Let's say the hour of the test is 23h50 in GMT+0. The slot will be created at 23h50 in GMT+0. But if the time zone of the environment is set at GMT+1, at the moment of the `_compute_datetime`, we will call this piece of code, where we will translate 23h50 to GMT+1, we will obtain 00h50, then only return the day, which offsets the result of one day in the future. X-original-commit: d91c53869842f65a60088ffa101f67404af6e58e note: backport of https://github.com/odoo/enterprise/pull/108891 Forward-Port-Of: odoo/enterprise#110126
This update fixes a visual issue on mobile devices where folded columns would appear incorrectly. The layout is now correctly handled when the browser window is pinned, and the 'unfold' button is hidden since this feature isn't available on mobile. This ensures a consistent and functional experience for users.
Original PR description
Before this PR, when a user pinned the browser window to one side (using another app side by side), any folded column would still be displayed empty and with a large size, even though the folding functionality is not available on mobile. With this update, the folded column layout is fixed on mobile and the unfold button is now hidden, as this functionality is not available. task-5391942 commu-PR: https://github.com/odoo/odoo/pull/245868
This update resolves a failing test related to the point-of-sale platform's order flow. The system now requires a kitchen printer, but the test environment lacks this setup, causing errors. This fix ensures the test passes and the platform functions correctly.
Original PR description
This commit fixes the failing `test_platform_order_flow` test, specifically within the `test_platform_order_reject_flow` tour at the `.ticket-screen` step. Explanation: The root cause of this issue is that the system is now expecting a kitchen printer to be present to process the order flow. However, the unit test environment does not have a kitchen printer configured, which causes the flow to halt or behave unexpectedly when the system tries to interact with it. Reference: Breaking PR: odoo/odoo#226447 build_error-241246
This update resolves intermittent test failures in the sign functionality by using dedicated test users instead of the default 'admin' and 'demo' accounts. This ensures consistent and reliable test results, improving the overall stability of the sign process. The change enhances the quality and predictability of our automated testing.
Original PR description
Relying on the default `admin` and `demo` users caused random runbot failures, as their access rights can be altered by other modules. This commit replaces them with freshly created test users to strictly simulate the presence or absence of the `sign.group_sign_user` group, ensuring the test remains deterministic. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/241216
This update fixes an issue where bank statement reconciliation in foreign currency journals incorrectly converted currency amounts. When reconciling batch payments, the system now uses the correct payment currency, ensuring accurate balance calculations and reporting. This improves the reliability of financial reconciliation processes.
Original PR description
When reconciling a batch payment in a foreign currency journal where payments do not have outstanding accounts, the resulting bank statement lines could use the wrong currency for balance conversion. Steps to reproduce: - Create a journal in a foreign currency (e.g., CHF) - Create two invoices in company currency (e.g., EUR) - Pay both invoices using the foreign journal - Create a batch payment for these payments. - Reconcile a bank statement line against this batch payment. Issue: Reconciliation make use of the payments amount in the wrong currency. Analysis: During the reconciliation of a batch payment, the system creates new amls from the payment values. However, the currency of the computed amount should be the source payment currency, and not the invoice line currency. opw-5887218 Forward-Port-Of: odoo/enterprise#108745
This update corrects a bug where archived employee versions continued to appear in pay run reports. The fix filters pay runs to only include currently active employees, ensuring accurate payroll calculations. This resolves a potential reporting issue and maintains data integrity.
Original PR description
Steps to reproduce: 1. Create an employee with a contract for this month 2. Archive the employee (but not the version) 3. Create a pay run 4. The employee's version will appear in the list Cause: The domain takes versions for archived employees. Fix: Add active_employee in the domain. Task: 6022437 Forward-Port-Of: odoo/enterprise#110073
This update fixes an issue where customers could inadvertently set subscription start dates to 'false', leading to incorrect invoicing. The change prevents users from removing the start date, ensuring subscriptions are properly billed and tracked. This maintains accurate subscription records and prevents revenue discrepancies.
Original PR description
**Issue** Some customers were removing the `start_date` of subscriptions, leading to the subscription being considered free on the next invoicing. While there are legitimate use cases to edit the `start_date` of a running subscription, it should probably not be removed. opw-5325303 Forward-Port-Of: odoo/enterprise#104925
This update resolves a technical limitation in the Odoo Report Editor that prevented users from applying properties to certain fields. Previously, the /field command in the editor didn't support properties, leading to functionality restrictions. This fix ensures proper property support for fields within the report editor, improving its usability.
Original PR description
Properties are not supported in ir.qweb but only as t-out, while t-field doesn't support them. For this reason and the fact that properties have a path the model field selector barely handles we do not allow those field to be selected in the /field command task-5999790 Forward-Port-Of: odoo/enterprise#109486
This update fixes a potential error in how Odoo retrieves Instagram poll IDs. Previously, attempting to get the ID before a poll was fully published would cause an API error. Now, Odoo checks the poll's status first and only requests the ID when it's confirmed as 'PUBLISHED'. This ensures smoother operation and prevents errors, improving the reliability of Instagram polls.
Original PR description
Follow-up to 06256aa02cb92378933edd638259dd725a2d04c1 The Instagram API returns an error if the `ig_id` field is requested while the container is still processing. This commit splits the container status check into two steps: 1. Poll for `status_code` only to determine the current state. 2. If the status is `PUBLISHED`, perform a second request to fetch the `ig_id`. Updated the test mocks to simulate this restriction, ensuring that requesting `ig_id` on a non-published container results in a 400 error to prevent future regressions. opw-5081325 Forward-Port-Of: odoo/enterprise#110094