Daily updates from Odoo
Tuesday, September 9, 2025
39 changes · saas-18.4
New functionality added to Odoo
A new shared KPI provider lets Odoo modules publish business metrics in a consistent way. Accounting now uses it to report draft document counts by type, helping future dashboards or reports collect these figures more easily.
Original PR description
This commit introduces a new abstract model `kpi.provider` that allows different modules to contribute their Key Performance Indicators (KPIs) in a modular and extensible way. The `kpi.provider` model defines a base structure for KPI reporting and includes a `get_kpis_summary` method that should be overridden in inheriting models. This method is responsible for returning a list of KPI data specific to the module. KPI data are identified by a unique name and a type allowing for the caller to know how to present the corresponding value. The `account` module inherits from `kpi.provider` to include the amount of draft `account.move` for each `move_type`. Task-id: 5062431 Forward-Port-Of: odoo/odoo#225153
The KPI summary now highlights how many documents are waiting in the Inbox and shows the current status of pending tax return types. This gives teams a quicker overview of outstanding document work and compliance deadlines without opening each area separately.
Original PR description
With this commit, `kpi.provider.get_kpi_summary` will show how many documents are present in the Inbox folder, as well as the status of the `account.return.types` (`late`, `longterm`, `to_do`, `to_submit` and `done`) depending on which account.return are not completed and on their due date. Task-id: 5062431 Forward-Port-Of: odoo/enterprise#93720
Enhancements to existing features
The Nilvera integration for Turkish e-invoicing now syncs statuses and PDFs for both E-Invoices and E-Archive documents, including invoices created directly in Nilvera. This helps users see up-to-date invoice results in Odoo, with retrieved PDFs shown in preview and attached automatically for easier record keeping.
Original PR description
[IMP] l10n_tr_nilvera_einvoice: refactor API to include E-Invoices & E-Archive Fixed bugs in API calls triggered during fetch requests and added support for fetching the status of E-Archive files. Updated the action button label to "Sync with Nilvera", which now fetches invoice statuses, retrieves PDFs for both E-Archive and E-Invoices, and includes invoices generated directly in Nilvera, enabling support for additional invoice types currently not supported in Odoo. Invoices/Bills are marked as "Successful" once retrieved. Retrieved PDFs are displayed in the preview and automatically attached to the chatter. The original limit of fetching a maximum of 30 records (status and PDFs) is maintained. task-4714467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224799 Forward-Port-Of: odoo/odoo#223599
Users can now rename online bank synchronization links directly from the form view. This helps businesses distinguish between multiple connections to the same bank and manage them with less confusion.
Original PR description
With some provider, you can have several links to the same bank. This can be confusing for the user. Allowing to edit the sync name from the form view can help the user sort out its links. Not a FIX, but suggestion is from opw-5004182 Forward-Port-Of: odoo/enterprise#93538
Resolved issues and error corrections
This update fixes an issue in the India localization and India sales localization test setup where company context was being changed in a way that could fail after initialization. It improves reliability for maintaining Indian tax and fiscal position behavior without changing business workflows.
Original PR description
In this PR: - Replaced direct assignment `self.env.company = self.default_company` with proper odoo environment switching pattern to avoid AttributeError when company attribute becomes read-only after initialization. Forward-Port-Of: odoo/odoo#224795
The website editor preview for floating block sections now applies background positioning consistently across all blocks. This helps users see a more accurate preview while editing, reducing surprises when the page is published.
Original PR description
This commit fixes an issue with the `s_floating_blocks` snippet where some CSS rules were inactive due to the selector. Previously, the snippet applied a `background-position: top` property to the first block. However, this rule was ineffective because the first block does not include a `s_parallax_bg`. This commit resolves the issue by allowing all blocks to receive the `background-position` property, ensuring the behavior is fully WYSIWYG for the user. task-5068688 Forward-Port-Of: odoo/odoo#225918
This fixes an issue where visible product tags could disappear from the online shop after migration if the default product variant had no customer-visible tags. Customers can now see the appropriate tags for each variant, improving product information accuracy on the website.
Original PR description
### Steps to Reproduce: 1. Create a database of version 18.0 to 18.3 with the website and website_sale modules installed. 2. Create a product and add some variants for that product. 3. Assign product…
### Steps to Reproduce: 1. Create a database of version 18.0 to 18.3 with the website and website_sale modules installed. 2. Create a product and add some variants for that product. 3. Assign product tags to all variants. 4. In the default variant of the product, add tags where visible_to_customer = False. 5. Migrate that database to version 18.4. ### Issue: After migration, product tags are not shown for any variant If the default product variant has no visible tags. This happens because of the condition: `t-if="any(tag.visible_to_customers for tag in all_product_tags)"` defined in website_sale.product_tags [view](https://github.com/odoo/odoo/blob/saas-18.4/addons/website_sale/views/templates.xml#L2337-L2361) Here, the template is always rendered with all_product_tags from the [default variant](https://github.com/odoo/odoo/blob/saas18.4/addons/website_sale/views/templates.xml#L1979-L1987). So, if the default variant has no visible_to_customer tags, the condition fails, and as a result, tags from other variants are never displayed—even if they are visible. ### Fix: Remove the redundant outer condition: `t-if="any(tag.visible_to_customers for tag in all_product_tags)"` Since inside the loop we already have: `<t t-if="tag.visible_to_customers">` which checks visibility for each tag individually across variants, There’s no need for the extra wrapper condition. This ensures product tags are displayed correctly for all variants that have visible_to_customers = True, regardless of the default variant’s tags. OPW - [5031068](https://www.odoo.com/odoo/project/70/tasks/5031068) UPG - [3114696](https://upgrade.odoo.com/odoo/upgrade.request/3114696) Description of the issue/feature this PR addresses: #### Current behavior before PR: The product tag is not visible on the website, even though the tag is visible to customer <img width="700" height="500" alt="image" src="https://github.com/user-attachments/assets/64bea4b4-314a-4595-8b46-b93b745086b0" /> #### behavior after PR is merged: The product tag is visible now <img width="700" height="500" alt="image" src="https://github.com/user-attachments/assets/694cc0c8-fc92-441c-b7be-e835298fbec2" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an accounting issue where reverse charge taxes with offsetting repartition lines could show both manual tax amounts as positive. This helps ensure tax entries reflect the correct sign, improving accuracy in accounting records and reports.
Original PR description
When a tax is defined using +100, -100 as repartition lines, the tax amount retrieved from manual_tax_amounts where positive for both lines. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225855
Odoo no longer saves an internal browser database version that could become outdated when the same app was opened in multiple tabs. This prevents cache failures and console errors, helping pages load more reliably in fresh browser sessions.
Original PR description
Open Odoo in two tabs, in a fresh browser (or delete the IndexedDB). - Open the Contacts app in the first tab; - Open the Contactc app in the second tab; Before this commit, the second tab will not use the cache, and an error will be displayed in the console : `IndexedDB error: The requested version is less than the existing version`. This issue occurs, because the IndexedDB wrapper stores the database version, which is incremented when a new table is needed in order to execute the `onupgradeneeded` function and create the table. Now, the version is not stored anymore. When a new table is needed, the database is opened with the current version + 1. This will execute the `onupgradeneeded` function and create the table. Forward-Port-Of: odoo/odoo#226015
This fix makes an automated online shop test wait for the expected page element before moving to the next step. It reduces false test failures caused by timing issues, helping keep website sales changes more stable during validation.
Original PR description
Some tour steps executed too quickly and did not wait for the target element to appear, causing race conditions where the next step failed due to missing elements. This commit adds an explicit check step between the failing steps to ensure the element is present before continuing, guaranteeing stable tour execution without premature step execution. runbot-229723 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
This fix prevents accounting setup from trying to use chart templates from localization modules that are not currently installable. It reduces unnecessary errors when custom or inherited localization modules are present but not ready to be installed.
Original PR description
* Problem: if having a custom module that add extra tax to current localization module, ex: l10n_x inherit l10n_vn module, but the l10n_x module is not installable because it hasn't upgraded yet, the _get_chart_template_mapping include it as well, there for will log error in https://github.com/odoo/odoo/blob/18.0/addons/account/models/chart_template.py#L1219 * Solution: only get available template code for module that installable 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#225821
The checkout button now appears in the shopper's selected website language when Cash on Delivery is used. This prevents a mixed-language checkout experience and improves clarity for multilingual customers.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Enable the Cash on Delivery payment method; 2. have a delivery method which allows cash on delivery; 3. active a second language on the website; 4. go to /shop/payment in the other language; 5. select Cash on Delivery payment. Issue ----- The "Place order" button isn't translated. Cause ----- The `delivery` module isn't listed as "front-end module" for translation purposes, making the translated term unavailable there. Solution -------- Add `delivery` as a front-end module via a `_get_translation_frontend_modules_name` override. opw-4971473 Forward-Port-Of: odoo/odoo#225940
Romanian electronic bill imports now ignore invalid PEPPOL endpoint data found in ANAF XML files before creating a new partner. This prevents unnecessary import errors being logged when government-provided data contains an invalid endpoint.
Original PR description
Problem --------- When importing the bill, the XML contains a faulty PEPPOL Endpoint (an address mail). Since the partner in the XML does not yet exist in the client database, we attempt to create it with the name, VAT, address and the faulty endpoint; which, triggers an error that is logged in the chatter. For unknown reasons, the RO government allows for such error to be introduced but since we can't change ANAF itself, we have to make a fix to manage the case. Solution --------- When importing the partner data from the XML, we check if the endpoint is valid before creating the partner. If it is not the case, we simply remove and ignore the endpoint data. opw-5046567 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Stripe setup from trying to enable payment methods that are not compatible with manual capture. Businesses can activate supported payment options without confusing warnings or failed activation attempts.
Original PR description
Steps to reproduce: 1) Check the manual capture checkbox on Stripe. 2) Try to enable it. 3) See the warning that some payment methods can not be activated. Reason: Commit 25feb5b11c2df401580b65e0108145863fcf8987 disallows activating payment methods that do not support manual capture if their provider supports it. Solution: Filter out incompatible pms. opw-4860912 Forward-Port-Of: odoo/odoo#223038
This fixes a display issue where long live chat conversation names could be clipped in the sidebar after a conversation ended. Users can now read the full relevant channel name more reliably, improving navigation and reducing confusion.
Original PR description
Since PR #217615, when a livechat conversation ends, an italic class is added to the thread name classes in the sidebar. As a result, the thread name may be clipped in the sidebar if it is long enough. This change ensures that the thread name is displayed correctly. Before: <img width="310" height="56" alt="image" src="https://github.com/user-attachments/assets/3b289c01-bf11-4f4e-9555-e45a89641975" /> After: <img width="317" height="56" alt="image" src="https://github.com/user-attachments/assets/676eaa5b-e83d-4f77-b320-a9c525d4dce2" />
TicketBAI submissions could fail when a point of sale name created an invoice series longer than Spain's required 20-character limit. The system now shortens that value before submission, preventing a confusing upload error and helping affected POS orders send successfully.
Original PR description
Before this commit, records with sequences over 20 characters will present a cryptic error when uploaded to TicketBAI. Steps to reproduce ----- 1. Create a point of sale with a name >20 characters 2. Validate an order on the POS 3. Go to Point of Sale > Orders > Your order, click "Send to TicketBAI" 4. Invalid Operation ``` 002: Fichero no cumple el esquema XSD. Detalle del error: cvc-maxLength-valid: Value 'ThisisaveryveryveryveryverylongPOSnameTEST' with length = '42' is not facet-valid with respect to maxLength '20' for type 'TextMax20Type'. ``` Issue ----- The schema for SerieFactura specifies a TextMax20Type, but the generated sequence can be over 20 characters. Solution ----- Truncate the sequence to 20 characters. opw-4750372 Forward-Port-Of: odoo/odoo#225776 Forward-Port-Of: odoo/odoo#225436
Users can now refuse a job application using a reason that has no email template without triggering an error. This prevents an unexpected crash in the recruitment workflow and lets teams continue processing applications normally.
Original PR description
When user tries to select a refuse reason without Email Template in Application, A traceback will appear. Steps to reproduce the error: - Install ``hr_recruitment`` module - Go to Recruitment > Configuration > Refuse Reasons > Create a new Reason without Email Template - Create a Application > Refuse > Select refuse reason without email template Traceback: ``` UnboundLocalError: cannot access local variable 'wizard_field_name' where it is not associated with a value ``` https://github.com/odoo/odoo/blob/f6874befe64daf78dc59fa09a349cad305717bed/addons/hr_recruitment/wizard/applicant_refuse_reason.py#L99-L104 Here, the ``wizard_field_name`` variable is referenced before the assignment, So, It will lead to the above traceback. sentry-6844982581 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Online product pages now update the displayed price when shoppers change the quantity to meet a pricelist discount threshold. This helps customers see the correct discounted price before adding items to their cart, reducing confusion and pricing mismatches.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Create a pricelist with a discount based on a min quantity; 2. have the pricelist available in eCommerce; 3. open a product page where the discount can get applied; 4. change the quantity in the selector to the minimum for the discount. Issue ----- The product's price doesn't get updated to show the discount. Cause ----- The `_onChangeAddQuantity` function, which is supposed to update the price, is applied to the `form .js_product:first [name="add_qty"]` selector, but as of saas-18.4, the `form` element is located inside of the `.js_product` element, making it no longer work. Solution -------- Change the selector to `.js_product:first form [name="add_qty"]`. opw-5037669
New car requests from the Belgian salary configurator will no longer make an employee's current car appear available too early. This prevents confusion or accidental reassignment while the new car is still only at the request stage.
Original PR description
When a new car is ordered through the belgian salary configurator, a car is created in the stage 'New Request'. At this state, nothing is planned to change the car so we don't want to set the existing employee car as available for someone else. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223589
Livechat agents now see a visitor's recent page visit times in their own timezone instead of UTC. This makes the browsing history banner easier to understand and helps agents respond with the correct context.
Original PR description
Before this PR, when browsing a website livechat in the discuss app, the banner containing the 3 last pages browsed by the user showed the utc time instead of the time in the timezone of the agent. Now, the livechat agent is seeing the visit timings in his timezone. To achieve this, we now construct the visit string in the frontend and receive the page and datetime (utc) info from the backend task-4937769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225602 Forward-Port-Of: odoo/odoo#219113
This fixes an issue where Romanian e-invoicing synchronization could fail with a technical traceback when a communication error occurred. The system now checks the error information in the correct place, helping users receive proper synchronization feedback instead of an unexpected crash.
Original PR description
Problem
---------
Currently, the 'error' message (in case of communication error) is stored in the 'answer' dict. However, the code verify for the 'error' key in the message dict itself.
Solution
---------
When checking if the 'error' key is present, check in the 'answer' dict rather than the message dict
The code is
```message = {**data, 'answer': {**data, 'error': ""}}```
The verification were
``` 'error' in message ?```
and now they are
``` 'error' in message['answer'] ?```
opw-5046567
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixes a website builder error that could appear when users removed a parallax effect from a background image inside another image-backed section. This makes editing nested website elements more reliable and prevents disruptive traceback popups during page design.
Original PR description
Before this commit, setting parallax to "none" for elements nested inside other elements with a background image caused an error. The issue occurred because the function `showMainColorPicker` was…
Before this commit, setting parallax to "none" for elements nested inside other elements with a background image caused an error. The issue occurred because the function `showMainColorPicker` was called after the `.parallax` span element was removed. Since the `.parallax` element is the editingElement of this option, the function should not have been invoked in the first place. This commit fixes the issue by querying the editing element only once during the setup of `BackgroundImageOption`. This ensures that even if `showMainColorPicker` is called after the `.parallax` element is removed, no error occurs. How to reproduce The problem can be reproduced with many combinations of nested elements. For example: 1. Place the `s_three_columns` snippet 2. Set a background image for the whole snippet 3. Set a background image for a single card 4. Set a parallax effect for the card background image (e.g.: "Scroll Effect" -> "Fixed") 5. Set the same parallax effect back to "none" (Scroll Effect -> "None") 6. Traceback pops up task-4367641
This update prevents an error message from appearing in debug mode when translating selection field labels on website forms. It improves the reliability of the website translation workflow without changing visible functionality for regular visitors.
Original PR description
**PROBLEM** In debug mode, props type errors pop up when clicking on a selection field to translate it. **STEP TO REPRODUCE** 1. Create a form with a selection field in a page. 2. Ensure you're in debug mode assets. 3. Go in translate mode, and click on a string of the selection field to translate it. 4. Props type error should pop up. **CAUSE** `node` is actually of type `Object` (its the target of a jquery event), the props validations expect it to be of type `String`. opw-4896491 Forward-Port-Of: odoo/odoo#221876
A flaky website builder animation test is being skipped temporarily to prevent random test failures. This helps keep automated checks reliable while the team investigates a long-term fix.
Original PR description
The test fails non-deterministically. We sip it while looking for a long term fix task-4367641
Switching developer mode on or off now shows the correct Calendar meeting tabs after a single refresh. This prevents users from seeing outdated cached screens and avoids confusion when debug-only options should appear immediately.
Original PR description
**Steps to reproduce:** - Go to Calendar app - Go to any meeting - Invitations tab should be hidden (no debug mode) - Trigger developer mode (`?debug=1`) - Invitations tab should be displayed - The…
**Steps to reproduce:** - Go to Calendar app - Go to any meeting - Invitations tab should be hidden (no debug mode) - Trigger developer mode (`?debug=1`) - Invitations tab should be displayed - The tab only appears after a second refresh **Issue:** The new caching process uses a key based on the RPC parameters. In the case of the 'get_views' function, it produces a different result with the same parameters depending on whether debug mode is enabled. This means that two browser refreshes are needed to have the correct view. The first refresh renders the cached view (without the invitation tab) and updates the cache with the view returned by the RPC (with the invitation tab). The new cached view with the invitation tab will be rendered on the second browser refresh. **Fix:** Add the debug option to the RPC parameters to cache the different views separately (with and without the invitation tab). opw-4986038 related: https://github.com/odoo/odoo/commit/f3d955b3235cb256bda79e834df38da0f6a4ac1a Forward-Port-Of: odoo/odoo#223401
Vendor bill printouts in Chile now use the standard report layout unless they are specific electronic purchase invoices. This prevents company and customer details from appearing swapped, making printed bills clearer and more accurate for accounting teams.
Original PR description
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type…
steps to reproduce: ------------------- 1. Install `l10n_cl`. 2. Create a new company and set Chile as the country. 3. Go to Accounting > Configuration > Journals. 4. Create a journal with type Purchase and enable Use Documents. 5. Go to Accounting > Vendors > Bills and create a bill. 6. Print Invoices / Invoices without payments. issue: ------ The customer and company data are swapped (interchanged), and It is wrong from vendor bills point of view. solution: --------- The l10n_cl reports layout should only be applied to: - out_invoice or out_refund - or when l10n_latam_document_type_id = (46) Electronic Purchase Invoice **Before:** <img width="762" height="425" alt="image" src="https://github.com/user-attachments/assets/e042485b-5d82-455f-9f34-03a0a9cdf5cc" /> **After:** <img width="770" height="624" alt="image" src="https://github.com/user-attachments/assets/c5d09e58-bcf0-48ab-a0ae-0e37c0473a67" /> opw-4937097 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224454
This fixes an error that could block users from sending a credit note after recording a partial payment. Businesses using electronic invoicing can now complete this workflow without encountering a system traceback.
Original PR description
When User sends the partially paid credit note, A traceback will appear. Steps to reproduce the error: - Install ``l10n_co_dian`` module with demo data and switch to CO Company - Create a Credit note > Confirm > Register a partial payment > Send > Send Traceback: ``ValueError: The following child node is not defined in the template: CreditNote/cac:PrepaidPayment`` https://github.com/odoo/odoo/blob/7136383f47f3f86bc803efaa3837f4879b211b11/addons/account_edi_ubl_cii/tools/ubl_21_credit_note.py#L26 Here, ``cac:PrepaidPayment`` node is missing in the CreditNote. So, It will raise the above traceback when sending the credit note. sentry-6814211355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223527
Fixes an issue where extra hours time off could be approved after refusal without deducting the used duration. This ensures employee time off balances remain accurate and prevents repeated use of the same extra hours.
Original PR description
Steps to reproduce: - On the time off dashboard, create a new leave with the type "Extra hours" - Click on the request again, refuse the request - Click on the request, and now approve the time off -If you now try to create a new time off with the type "Extra hours", you'll notice that the duration of the previously "refused then approved" time off is not taken into account Reason: The action tied to the "Approve" button was wrongly named in the inherited hr_leave model of the hr_holidays_attendance module, which prevented the computation for the approval to be taken into account. How it was fixed: Correcting the name allowed the function to be called properly and the calculation is now performed correctly. Task ID: 5051271 Forward-Port-Of: odoo/odoo#225623 Forward-Port-Of: odoo/odoo#224992
Duplicated automatically created reconciliation models are now treated as regular copies, so they appear in the expected filters right away. Archiving a reconciliation model also cleans up related manual unreconciled statement-line assignments, reducing confusion for accounting teams.
Original PR description
When duplicating an automatically created reco model, the field created automatically was still set to True and so the filter doesn't show the reco model at first. By adding the copy=False it solve the problem Also, this commit will remove any manual reco model of unreconciled statement line when archiving that reco model. no task id
German tax report XML exports now keep periods as decimal separators, matching ELSTER's current import requirements. This prevents VAT return amounts from being ignored during submission due to invalid number formatting.
Original PR description
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax…
**Steps to reproduce:** 1. Install `l10n_de_reports` module. 2. Configure a company with a valid SteuerNummer. 3. Post some vendor bills with `19% I` VAT. 4. Go to *Accounting → Reporting → Tax Report*. 5. Export the report to XML from gear icon. **Observed behavior:** - The generated XML contains amounts with a comma `,` as the decimal separator. - Elster ignores values with commas, so amounts are missing from the submitted VAT return. **Root cause:** - The QWeb XML export replaced the decimal point `.` with a comma `,`. - Elster launched a new tax return application (*einfachELSTERplus*), which enforces `.` as the decimal separator. **Solution:** - Stop replacing `.` with `,` when exporting values to XML. - Keep amounts as floats with period separators, while still rounding or inverting values as required for specific Kz fields. **ref:** https://www.elster.de/eportal/helpGlobal?themaGlobal=osseust_import opw-4935738 Forward-Port-Of: odoo/enterprise#94130 Forward-Port-Of: odoo/enterprise#93623
The WhatsApp integration now uses the latest supported Meta Graph API version. This helps avoid service disruptions from older API versions being retired and reduces the need for repeated short-term updates.
Original PR description
As outlines in the version [changelog] v17 of the API which we are currently using will be converted to the next oldest supported version of the API as per [policy] We can migrate directly to the latest version and avoid any issue in the next few years instead of having to worry about potentially breaking changes every few months. [changelog]: https://developers.facebook.com/docs/graph-api/changelog/versions/ [policy]: https://developers.facebook.com/docs/graph-api/guides/versioning task-4971841 Forward-Port-Of: odoo/enterprise#94110 Forward-Port-Of: odoo/enterprise#93170
Portal users who are invited to edit a Knowledge article no longer see controls for publishing the article publicly or changing other members' access rights. This prevents confusing permission errors and keeps article sharing options aligned with the user's actual privileges.
Original PR description
Steps to reproduce =============== As an admin ---------------- 1. Go to knowledge 2. Open any article. 3. Add a portal user as a member with write access. As a portal user -------------------- 1. Open the shared article. 2. On the top right corner, click on members button --> List of members along with their rights will be shown. The portal user can open the dropdown to alter the rights of other members. Though doing so will raise an AccessError (in the logs). After this commit, the portal user will *no* longer see the 1. Toggle to share article to the web. 2. Dropdown to modify members' rights. Task-4863456 Forward-Port-Of: odoo/enterprise#89394
Fixed an issue where subscription payments made through the portal could create and send the same invoice twice when automatic invoicing was enabled. This prevents duplicate EDI-signed invoice documents and reduces customer confusion and accounting cleanup.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Use a localization that uses EDI-signed invoices; 2. enable `sale.automatic_invoice` via `ir.config_parameter`; 3. pay for a subscription via the portal. Issue ----- Invoice is generated twice. Cause ----- Commit 7c5fd63729c1 added automatic EDI invoice signing for subscriptions paid via portal. This assumed that the `sale.automatic_invoice` parameter remained unset. If this parameter is set, the invoice is already generated when post-processing a transaction in `sale`. Solution -------- Don't send invoices whose `is_move_sent` field is set to `True`. Also, don't set `from_cron` to `True` on automatic payments, as this is only intended for moves that have `sending_data` filled by `account.move.send.batch.wizard`. opw-4648189 Forward-Port-Of: odoo/enterprise#93881
German accounting reports now correctly assign the required DATEV main account when a POS session includes both sales and refunds with different tax rates. This prevents missing account information in DATEV exports and helps ensure accurate reporting.
Original PR description
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to…
In _get_datev_account, the l10n_de_datev_main_account_id is determined by identifying a singular debit or credit account used in the journal entry. If there’s no unique account, it falls back to searching for a unique non-tax line among debit or credit lines. In POS, however, there is the possibility of generating journal entries that break this flow: - In a single POS session, add product A with tax 19% and product B with tax 7%. - In the same session, refund product A. - Close the session to generate the entries. In the resulting entry, since both sale and refund are present, it is not possible to discriminate using debit and credit amounts alone, and as a result, the field l10n_de_datev_main_account_id is not populated. Since account 1411 is always the one to be used for l10n_de_datev_main_account_id in this specific case, this commit adds a final fallback filter to select the correct line and ensure the field is populated. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4915272) opw-4915272 Forward-Port-Of: odoo/enterprise#92664
The website appointment editor now correctly applies the guest booking setting when it is turned on or off. This prevents accidental changes to whether customers can add guests to appointments, improving reliability for appointment setup.
Original PR description
Since https://github.com/odoo/enterprise/commit/689a2186fbe3b932b90bef3b64716c8443bad551, The website editor option for allow_guests has an inverted behavior, being toggled when it should not and vice versa. This is only due to a small inversion of values when refactoring the website builder code. Inverse the values when the option is on/off to match expected behavior. Task-4930982
Reinstalling the SEPA Direct Debit module no longer causes an error when pre-notification settings are not yet available. This prevents disruption when managing SEPA payment configurations and keeps batch payment setup reliable.
Original PR description
**Issue** When creating a batch payment with SEPA Direct Debit as payment method, if the user uninstalls the SEPA module and then installs it again, Odoo raises a `TypeError: 'int' object is not…
**Issue**
When creating a batch payment with SEPA Direct Debit as payment method, if the user uninstalls the SEPA module and then installs it again, Odoo raises a `TypeError: 'int' object is not iterable`.
**Steps to Reproduce**
1. Create a batch payment with SEPA Direct Debit.
2. Uninstall the `account_sepa_direct_debit` module.
3. Reinstall the module.
**Root Cause**
During module (re)installation, the compute method `_compute_sdd_required_collection_date` is triggered before any SEPA mandates or their pre-notification periods exist. This makes `mandates.mapped('pre_notification_period')` return an empty list. The code then calls:
max(minimum_offset, *mandates.mapped('pre_notification_period'))
When the list is empty, this reduces to `max(minimum_offset)`, which is invalid since `max()` with a single integer argument expects an iterable and raises a `TypeError`.
**Fix**
Handle the empty case so that there is a valid fallback both during installation and when mandates have no configured pre-notification period.
Opw-5042153
Forward-Port-Of: odoo/enterprise#93598Fixed an issue where changing a website form to send outgoing emails could trigger an error when visitors submitted it. The form now refreshes correctly after the model change, ensuring required hidden fields are added and submissions work as expected.
Original PR description
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. -…
Currently, an error occurs when submitting the 'Send Email' form. Steps to Reproduce: - Install the `website` and `web_studio` modules. - Go to `website` > `Click on Edit` > `Drag and drop form`. - click the form and in actions select the `more models`, and select `outgoing mails(mail.mail)` model and `save`. - `Submit` the form, and the error appears in the `logs`. **Error:** `KeyError: 'website_form_signature'` **Cause:** This error occurs when submitting the "Send Email" form from the website. By default, the form action is `"Send an E-mail"`, and when the user `changes` the form’s model to outgoing mails (mail.mail), which also has the action "Send an E-mail," the system checks the existing model [1] and retrieves it. Since `shouldRerender` is set to false, [2] is not executed, and as a result, the `email_to(hidden field)` is not present in the form. And the website_form_signature is added from [3], but due to the condition at [4], the code at [3] is not executed. When it is accessed at [5], KeyError is raised. **Fix:** This commit ensures that when the user changes the model, `rerenderXml` is executed so that the `hidden field` is also added. [1]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L155-L156 [2]: https://github.com/odoo/enterprise/blob/359a1c546fc9e4bc113517bf6ea912a70a9ea123/website_studio/static/src/website_form_editor.js#L174-L178 [3]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L252 [4]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/tools.py#L236 [5]: https://github.com/odoo/odoo/blob/82639728f2bcb4e7786f120de2aeba3f5fbab209/addons/website/controllers/form.py#L88 sentry-6746753251 Forward-Port-Of: odoo/enterprise#93287
When users open a Bill of Materials from the Master Production Schedule edit pop-up, the pop-up now closes automatically. This prevents an error when returning from the BOM screen and provides a smoother planning workflow.
Original PR description
Before this commit: ------------------------- Clicking the BOM field in the edit production schedule pop-up on the MPS page redirected the user to the BOM form view, but the pop-up remained open in…
Before this commit: ------------------------- Clicking the BOM field in the edit production schedule pop-up on the MPS page redirected the user to the BOM form view, but the pop-up remained open in the background. If the user then clicked Cancel on the pop-up, it created a traceback error. Steps to reproduce: ------------------------- 1. Install 'mrp_mps' module. 2. Go to Planning → Master Production Schedule. 3. Click the pencil icon next to a product. 4. In the pop-up, click the BOM value to navigate to the BOM. 5. Notice that the pop-up stays open even after redirection, and closing the pop-up raises a traceback error. Cause of the issue ------------------------- When your onClose arrow function directly executes this.reload(productionScheduleId) without curly braces, it immediately hands over the outcome of that function call to the dialog system. Since this.reload is an asynchronous operation with multiple sequential return values, its immediate outcome may not be a final value. After this commit: ----------------------- The pop-up is automatically closed when navigating to the BOM form view from the BOM field in the Edit Production Schedule popup, ensuring a cleaner and more intuitive user experience. Task Id: 4886331 Forward-Port-Of: odoo/enterprise#90424
Miscellaneous changes
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
Original PR description
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762