Daily updates from Odoo
Wednesday, January 21, 2026
28 changes · saas-18.3
Enhancements to existing features
This update enhances the user experience by adding a cursor pointer to the headers of statement summaries in the accounting module. This allows users to easily navigate and explore their financial data more efficiently. It's a simple change designed to improve usability.
Original PR description
This improves the user experience by indicating that the headers are clickable. No task ID
This update ensures Odoo correctly handles the new 11% and 21% VAT rates introduced in Romania. By adding missing tax mappings, the system now accurately reflects the latest Romanian VAT regulations and ensures proper fiscal position calculations.
Original PR description
The new 11% and 21% taxes introduced with the updated Romanian VAT law were added with this commit https://github.com/odoo/odoo/commit/2026212d0f7ffc217be3c6a2ff2abe5288c18afb , but some tax mappings were missing. This commit completes the setup by adding the required tax mappings, ensuring the new rates work correctly with fiscal positions. task-5480159 Forward-Port-Of: odoo/odoo#244602 Forward-Port-Of: odoo/odoo#243452
This update enhances the reliability of our IoT Box connections by directly using IP addresses instead of domain names. When LNA is enabled, the system now retrieves the IoT Box's IP address, preventing potential issues caused by DNS resolution delays. This ensures smoother data transmission and improved system performance.
Original PR description
In order to avoid DNS resolution issues, we now parse the domain to get the IP of the IoT Box if LNA is enabled.
This update adjusts the location of UBL test files within the system, streamlining the testing process for future developments. This change prepares the system for supporting varied invoice formats and enhances the ability to validate schema compliance. It’s a routine update to improve development efficiency.
Original PR description
This commit rearranges the UBL test files' subfolder to be one level higher, from `export/bis3/be` to `export/bis3/invoice/be`, in preparation for supporting different move formats and for better ignore schema support. task-4891206 Forward-Port-Of: odoo/odoo#244665
This update optimizes how Odoo generates reports by grouping related database queries. Previously, each report filter required a separate SQL query, which was slow. Now, multiple filters targeting the same data are combined into a single query, significantly speeding up report generation times – specifically, the Generic Balance Sheet now runs in 36 seconds instead of 1 minute 35 seconds.
Original PR description
Before this commit, the 'domain' engine was never batched: one expression to evaluate caused one SQL query to be run just for it. With this commit, we group domains that could be evaluated together. Essentially, when we have domains targetting the same many2one field of account.move.line (typically account_id, with conditions like 'account_id.code' or 'account_id.account_type'), we run only one SQL query for all of them, targetting all the move lines according to the report filters. Then, we iterate on its result for each domain to evaluate. When iterating over the results, we filter the ones we keep by searching separately on each traversing model (in our example, account.account), to isolate the ones that are actually targetted by each expression. Tested on our prod. With this, opening the Generic Balance Sheet goes from 1min 35s to 36s. opw-5130725 Forward-Port-Of: odoo/enterprise#101725
Resolved issues and error corrections
This update fixes an error in the Swiss VAT reporting module that was causing negative values to be displayed for reverse charge tax figures (382a and 383a). The fix adjusts how these figures are calculated to accurately reflect the reverse charge mechanism, ensuring correct VAT reporting for Swiss companies.
Original PR description
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or *…
**Steps to reproduce:** * Install the **l10n_ch** module for a Swiss company. * Create a vendor bill for a **foreign vendor**. * Apply a reverse charge tax: * **8.1% R C** (figure **383a**), or * **7.7% R C** (figure **382a**). * Confirm the vendor bill. * Go to **Accounting → Reporting → Tax Report**. * Generate the VAT report for the relevant period. **Observed behavior:** * Figure **383a** (8.1% reverse charge) is reported as **negative**. * Figure **382a** (7.7% reverse charge) is reported as **negative**. * This results in incorrect VAT reporting. **Cause:** * Reverse charge taxes use **negative tax rates** to model the reverse mechanism. * The base amounts were tagged with **positive** signs, leading to negative values in the report. **Fix:** * Invert the base tax tag signs for reverse charge taxes: * **382a**: change base tag from `-382a` to `+382a`. * **383a**: change base tag from `-383a` to `+383a`. * Reverse charge base amounts now appear as **positive** values in the VAT report. opw-5257445 Forward-Port-Of: odoo/odoo#244613 Forward-Port-Of: odoo/odoo#244452
This update fixes a problem where the file upload service wasn't properly handling errors from different types of Odoo API responses (JSON, JSONRPC, or HTML). Now, the service is better equipped to manage these errors, leading to a more stable and reliable file upload experience. This ensures users can consistently upload files without unexpected interruptions.
Original PR description
Odoo controllers often don't use coherent API they respond with either json, jsonrpc or html. On the client side, we have no reliable way to know this, and sometimes it is not possible to make a guess (rpc.js makes the guess that controllers are of json type -- actually meaning jsonrpc) The file upload service suffered from this and did not handle those error cases well. After this commit, the file upload service handles much of the errors. 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 Forward-Port-Of: odoo/odoo#244704
This update fixes a discrepancy in eWaybill invoices for exports to India. It now includes reverse charge (RC) amounts in the total invoice value, aligning with the Indian government's eWaybill system. This ensures accurate reporting and compliance with GST regulations.
Original PR description
For export invoices, the total invoice value in the eWaybill JSON did not include reverse charge amounts for GST, leading to a mismatch with the value shown in Odoo and the eWaybill generated by the Indian government system. This commit adjusts the JSON computation to include the reverse charge amounts in the total invoice value for exports, aligning it with the government-generated eWaybill, while preserving the existing reverse charge flow. task-5068199 Forward-Port-Of: odoo/odoo#243802 Forward-Port-Of: odoo/odoo#241852
This update fixes an issue where Odoo was creating duplicate contacts for vendor bills with slightly different VAT number formats (with or without dots). Now, Odoo will correctly identify and link bills with the same VAT number, regardless of formatting, ensuring accurate record-keeping and reporting. This improves data consistency and simplifies reconciliation processes.
Original PR description
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time)…
Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number Current behavior before PR: If you have two incoming vendor bills (over a period of time) where the first bill has these details: - VAT number: `BE0477472701` - Name: `Odoo` And the second bill (e.g three months later) has these details: - VAT number: `BE0477.472.701` - Name: `Odoo S.A` Odoo will do something interesting and will create a second new contact. The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo". However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701". Throughout Odoo however VAT numbers are parsed and stored without dots in it. The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots. Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same. Desired behavior after PR is merged: Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different. P.S: please find two sample XML's here: [sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml) [sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml) If you upload both back to back on a default V19 you will see two contacts. After this code change you will only see one contact where both bills are mapped to the same contacts. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244572
This update resolves an issue where accessing settings in the Romanian language version of the l10n_ro_edi_stock module resulted in an error. The fix ensures that settings can be accessed correctly when the Romanian language is selected for a company, improving usability for Romanian-speaking users.
Original PR description
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module…
**Issue**: When the module `l10n_ro_edi_stock` is installed and Romanian is the selected language, accessing the settings app causes a traceback. **Steps to reproduce**: - Install the module `l10n_ro_edi_stock` - Select a Romanian company - In Profile > My Preferences > select Romanian language - Try to access the settings -> A traceback occurs **Cause**: The error is caused by this XPath: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi_stock/views/res_config_settings_views.xml#L9C13-L11C21 Specifically, the `'select the option'` part. The XPath tries to replace this line in the parent view: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/addons/l10n_ro_edi/views/res_config_settings_views.xml#L39 but fails to find it because the source text has already been translated at that point, so `'select the option'` no longer matches: https://github.com/odoo/odoo/blob/2309fb56553e6ae9f89b6dd0947aba2f54408960/odoo/tools/template_inheritance.py#L154 **Solution** Only rely on strings that are translation-invariant. opw-5490346 Forward-Port-Of: odoo/odoo#244313
This update fixes an issue where the website's cookie consent settings weren't being saved correctly after changing the appearance of the 'I agree' button. The change in button style triggered an unintended closure of the consent modal, preventing the user's consent from being recorded. This ensures that cookie consent settings are reliably saved, improving user experience and compliance.
Original PR description
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape…
Steps to reproduce: =================== 1. Enable the Cookies Bar in website settings. 2. Go to the website and enter Edit mode. 3. Select the Cookie Bar and change the button "I agree" style shape to "Default" (this applies the `.btn-primary` class). & Save 4. Accept the cookies & refresh -> The cookie bar appears again because the consent was not saved. Cause: ====== The `CookiesBar` widget inherits from the generic `Popup` widget. The `Popup` class defines a default behavior for elements with the `.btn-primary` class: clicking them triggers `onBtnPrimaryClick`, which closes the popup. By default, the cookie bar button uses `.btn-outline-primary`, avoiding this behavior. However, when the user changes the style to "Default", the button receives the `.btn-primary` class. Consequently, the parent `Popup` handler is triggered. It closes the modal prematurely, interrupting the `CookiesBar`'s specific logic (specifically `onAcceptClick`),So onHideModal won't be called inside the function, and as a result, the user's consent cookie is never written. Solution: ========= Override the event to avoid side effects on hide. opw-5484578 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243562
This update resolves an issue where the map component wasn't displaying correctly within the Odoo Studio. The fix addressed a missing size constraint, allowing the map to render. However, the map remains non-interactive, indicating a separate problem that needs attention.
Original PR description
Before this commit, the map did not render in studio. This was because the container did not have a size. After this commit, the map renders correctly, but it is still not clickable or interactable. task-5432169 Forward-Port-Of: odoo/enterprise#104743 Forward-Port-Of: odoo/enterprise#104114
This update resolves an issue where multiple delivery reports were printed on the same page. The change in the report layout prevented automatic page breaks, causing reports with multiple deliveries to be combined. This ensures that all picking operations are displayed on separate pages for easier printing and readability.
Original PR description
When printing several picking operation at once, they are all in the same page. Steps to reproduce: ------------------- * Inventory>Operations>Deliveries * Create several Deliveries * Open list view to see all the deliveries * Select several deliveries * Print > Picking Operations -> All the picking operation report are on the same page. Observation: ------------- Since the change on the picking report layout https://github.com/odoo/odoo/pull/152280/changes#diff-7542c191def78bd64f54f1c33fde2c73e19e4d27f92b195c464d1d84e55b682fL6-R8 the report now uses a single article container for all records, this don't trigger automatic page break. opw-5481034 Forward-Port-Of: odoo/odoo#243817
A bug in the demo test setup was preventing it from correctly accessing necessary user permissions. This fix ensures the test accurately simulates real user access, specifically addressing a failure when testing the 'Overdue Customer Invoices' filter. The update adds the required access groups to the demo user, resolving the test failure.
Original PR description
__Steps to reproduce:__ 1. Create a new db with `contacts` and `account_followup` installed without demo data. 2. Run `TestMenusDemo` using `--test-tags click_all:TestMenusDemo`. => It fails when testing the "Overdue Customer Invoices" filter. __Reason:__ `TestMenusDemo` inherits from `HttpCaseWithUserDemo`, which creates a fake user demo if the database does not already contain one (meaning that it has no demo data). However, when doing so, it does not include all the access groups needed by the different modules. Since this filter requires access to `account.move.line`, an `AccessError` is raised and the test fails. __Fix:__ - Inside `TransactionCaseWithUserDemo` setup, add all the access groups in which Marc Demo normally is included to better represent the real flow. - Clean up the duplicate code. runbot-231045
This update creates a dedicated test company to isolate Shop Floor tests from demo data, ensuring more reliable results. It also re-enables key test tours related to Shop Floor operations, allowing for better validation of the system. This improves the quality and consistency of our Shop Floor testing procedures.
Original PR description
This PR does 2 things: ## Create a test company Add a company dedicated to TestShopFloor's tests so those tests won't be affected by demo data anymore. ## Enable tours Until then, 10 tours related to Shop Floor were skipped after [a refactor of the Shop Floor](https://github.com/odoo/enterprise/pull/80469) design and functionality. This PR re-enables 7 of these 10 tests tour (3 remaining need more work to pass when demo data are installed.) Also it adds a test helper method, `_enable_settings`, to enable wanted setting(s) easily. [task-5365014](https://www.odoo.com/odoo/966/tasks/5365014)
This update resolves an issue where registration emails for events were displaying duplicate headers and footers. The fix removed a redundant email layout setting that was causing this duplication. This ensures a cleaner and more professional email experience for event attendees.
Original PR description
**Steps to reproduce:** - Go to Event module - Go to an open event - Register for the event - Go to the Attendees of the event - On the attendee record, click `Send by Email` - The received email shows twice the header and footer **Issue:** Encapsulating notification layout was applied with `default_email_layout_xmlid` but the main template used is `event_registration_mail_template_badge` which already has its own header and footer. **Fix:** Removed the `default_email_layout_xmlid` opw-5032767 Forward-Port-Of: odoo/odoo#236667
This update automatically adjusts the start and end dates for salary certificate reporting in Odoo's Swiss localization module (l10n_ch_hr_payroll). Previously, these dates were static, now they dynamically pull from the configured data, ensuring accurate reporting for Swiss businesses. This change simplifies the process and reduces the risk of errors.
Original PR description
make Period until and from dynamic from data Forward-Port-Of: odoo/enterprise#104903
This update fixes an issue where role mentions were lost when editing messages in Odoo. Now, role mentions are correctly preserved during the editing process, ensuring accurate communication and collaboration within the system. This improvement enhances the reliability of message editing and avoids confusion for users.
Original PR description
**Current behavior before PR:** Editing a message with a role mention would cause the mention to be lost. **Desired behavior after PR is merged:** Role mentions are now preserved when editing a message. task-4702960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an error in VAT import bills. Previously, journal entries were incorrect due to a change in the default account used for VAT taxes. This fix updates the default account for three specific VAT taxes, ensuring accurate financial reporting.
Original PR description
Due to the change of account 33312 from liability to payable, the journal entries generated when creating bills with VAT import taxes were incorrect. This fix updates the default account on the following taxes: - tax_purchase_import_10 - tax_purchase_import_8 - tax_purchase_import_5 task-5695253 Forward-Port-Of: odoo/odoo#244434
This update resolves an issue where invoices sent to Viettel's SInvoice system were failing due to incorrect decimal formatting. The fix ensures the tax amount is calculated using the correct currency rounding method, preventing the 'INVALID_DECIMAL_POINT_TAX_MONEY' error and ensuring invoices are properly processed.
Original PR description
When sending an invoice to SInvoice (Viettel), the API raises an `INVALID_DECIMAL_POINT_TAX_MONEY` error if the tax amount contains excessive decimal places (e.g., 100.02999999999997). This occurs because the tax amount is currently calculated using simple subtraction (`total - subtotal`). Due to standard floating-point precision issues, this can result in unrounded values that the API rejects. The tax amount calculation is now updated to explicitly use the currency's rounding method, ensuring the value is accepted by SInvoice. task-[5484845](https://www.odoo.com/odoo/project/967/tasks/5484845) Forward-Port-Of: odoo/odoo#244647
This update ensures that delivery carriers are consistently applied across all stages of a multi-step delivery process, regardless of whether they're initially set on the sale order or manually configured during picking. This change addresses a previous limitation where carrier settings weren't propagated, now allowing logistics teams to manage carrier selection effectively.
Original PR description
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set…
Issue Before This Commit: ================================ Previously, the delivery carrier was only propagated between pickings when it was set from the sale order. If the carrier was manually set on a picking (e.g., during the packing step in a multi-step delivery flow), it was not propagated to the consequent pickings, even when the stock rules had `Propagation of carrier` enabled. Steps to reproduce: ================================ 1. Activate Multi-Step Routes and Delivery Methods. 2. Configure a 3-step delivery route in the warehouse and enable Propagate Carrier on all rules. 3. Create a sale order with a product but without setting a delivery carrier. 4. Confirm the sale order to generate picking. 5. On the first picking (i.e., pick), manually set a delivery carrier (e.g., Local Delivery) and validate. 6. On the next transfer (i.e., pack), observe that the delivery carrier is not propagated. After this commit: ================================ The delivery carrier set on any picking is propagated to subsequent transfers when the corresponding stock rule has `Propagation of carrier` enabled and no carrier is already configured on the next picking. This ensures consistent carrier propagation across all routing configurations (all pull rules, all push rules, and mixed push/pull flows), even when the carrier is configured at the picking level rather than on the sale order. This behavior is required because, in many business scenarios, carrier selection is managed by the logistics team rather than the sales team. task-4454313 Forward-Port-Of: odoo/odoo#202700
This update prevents excessive email notifications to managers when employees submit expenses. Previously, every state change triggered an email, leading to potential spam. Now, a weekly email is automatically sent to managers only if they have outstanding expenses awaiting approval, streamlining the approval process.
Original PR description
When an employee submits an expense and assigns a manager, an approval activity is scheduled. However, email notifications are now disabled to avoid spamming the assigned managers. * Prevent notifying the expense manager when expense state changes. * Email 'Next expense is waiting your approval' is scheduled to be sent to the manager once a week if the manager has any expenses left to approve. task-4676396 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210614
This update fixes several issues within the o_spreadsheet library, improving its performance and stability. It includes bug fixes related to spreadsheet calculations, data export, and chart rendering, ensuring accurate data representation and a smoother user experience. This update is part of the 18.3 release.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b7e5d912d0 [REL] 18.3.33 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b7e5d912d0 [REL] 18.3.33 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/a09dfc8fe1 [FIX] range: add result changeType [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/6533266efa [FIX] range: adapt string XC on sheet rename [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/3de6a75f5a [FIX] range: rename parameter [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/0e22d1fcc3 [FIX] range: add range to NONE [Task: 5095364](https://www.odoo.com/odoo/2328/tasks/5095364) https://github.com/odoo/o-spreadsheet/commit/cf8c57066d [FIX] Actions: ensure the sequence is applied on action children [Task: 5452669](https://www.odoo.com/odoo/2328/tasks/5452669) https://github.com/odoo/o-spreadsheet/commit/d48cfc2f24 [PERF] evaluation: don't spread single element matrix [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/dbdea6a2ca [FIX] evaluation: remove spread relation [Task: 5491138](https://www.odoo.com/odoo/2328/tasks/5491138) https://github.com/odoo/o-spreadsheet/commit/0158c42fa2 [FIX] chart: ignore NoChanges in gauge/scorecard side panel errors [Task: 5478288](https://www.odoo.com/odoo/2328/tasks/5478288) https://github.com/odoo/o-spreadsheet/commit/869ef2e9d8 [FIX] vectorization: fix error message on size mismatch [Task: 5331324](https://www.odoo.com/odoo/2328/tasks/5331324) https://github.com/odoo/o-spreadsheet/commit/f35a0cf0b3 [IMP] xlsx: export clip [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/c4b22807c8 [IMP] export: export align left when the cell content is a number; [Task: 5368130](https://www.odoo.com/odoo/2328/tasks/5368130) https://github.com/odoo/o-spreadsheet/commit/9213f2ee9e [FIX] header_size: wrong row size from wrapped number [Task: 4878338](https://www.odoo.com/odoo/2328/tasks/4878338) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves a minor performance issue within the o-spreadsheet plugin for quality control and sales management. Specifically, the way ranges are adapted has been optimized, resulting in faster spreadsheet loading and responsiveness. This ensures a smoother user experience for these key business processes.
Original PR description
…s args See https://github.com/odoo/o-spreadsheet/commit/6533266efa Task: 5095364
This update corrects a technical issue where Mexican tax documents weren't being properly updated. By forcing a write-date update, the system now accurately reflects the document's status, ensuring compliance with Mexican tax regulations. This resolves a previous limitation in the update process.
Original PR description
Before the commit 8b118a7, the search of the documents to update has been limited and ordered. With the actual domain the records to update will be most of the time the same because is not being updated. To fix this issue we force to update it. OPW-5368047 Forward-Port-Of: odoo/enterprise#103272
This update fixes a potential issue where Microsoft calendar synchronization could fail due to a short timeout when communicating with Microsoft's services. Now, administrators can adjust the timeout setting to accommodate slower environments or larger calendars, preventing synchronization failures and duplicate event creation. This enhances the reliability of calendar syncing.
Original PR description
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls…
**Description of the issue/feature this PR addresses:** Microsoft calendar synchronization may fail in environments with slower Microsoft Graph responses or large calendars because Graph API calls triggered after commit use a fixed 3-second timeout. This can lead to repeated synchronization failures even though the operation would succeed with slightly more time. Additionally, when creating events, the Microsoft Graph request may time out after the event is successfully created on Microsoft’s side but before the response containing the event ID is returned. In this case, Odoo does not store the ID of the event and may create the same event again during the next sync, resulting in duplicate events. **Current behavior before PR:** Microsoft Graph requests (insert, update, delete) are executed with a hardcoded 3-second timeout. If the Graph API response takes longer: • the synchronization fails, • and in the case of event creation, Odoo may not receive the Microsoft event ID even though the event was created remotely, which can lead to duplicate events in Odoo. **Desired behavior after PR is merged:** The Microsoft Graph request timeout is configurable via the optional system parameter `microsoft_calendar.graph_timeout`. If the parameter is not set, the behavior remains unchanged (default 3 seconds). Administrators can increase the timeout to allow successful synchronization in slower environments or with large datasets, reducing synchronization failures and avoiding duplicate event creation caused by missing Microsoft IDs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244461 Forward-Port-Of: odoo/odoo#241921
This update resolves a potential issue where Microsoft calendar synchronization could fail in slower environments. A previous timeout limit was too short, causing delays. This change allows for a configurable timeout, increasing the reliability of calendar syncing and ensuring appointments are properly synchronized.
Original PR description
Microsoft calendar sync can fail in slower environments due to a fixed 3s timeout for Graph requests triggered after commit. See community changes for details. Forward-Port-Of: odoo/enterprise#104916
Features or functions removed from Odoo
This pull request removes a no-longer-used folder within the Odoo Enterprise software. The folder, related to Russian localization ('l10n_in'), was identified as containing outdated files and has been safely removed. This cleanup improves the overall system organization and efficiency.
Original PR description
ref - https://github.com/odoo/enterprise/commit/ea7893a978c408e5d4437070ae7a6c7a7fbf7167 Forward-Port-Of: odoo/enterprise#104882