Daily updates from Odoo
Tuesday, September 9, 2025
28 changes · 18.0
Resolved issues and error corrections
Product images in the quotation catalog now display without being stretched when they are not square. This keeps product visuals accurate and improves the catalog browsing experience for sales users.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have products with non-square images available for sale; 2. open a quotation; 3. open the product catalog. Issue ----- The product images appear stretched. Cause ----- Commit e8836b42200e3 replaced the `div.kanban_image` element with a `field` element using the `image` widget. It maintained the same size limit of 55x55 via the widget's options, but without additional input, this causes the widget to stretch the images to fill the area. Solution -------- Add the `object-fit-contain` as `img_class` to the options. This class contains the image to the area instead of stretching it. opw-5007629
The Spanish Modelo 130 report now uses a date selector that matches how the report is calculated. Users choose the period end date instead of a custom range, avoiding confusion where results unexpectedly included entries from the start of the fiscal year.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#218544
Imported French FEC accounting entries now show correctly when users open a sales journal from the dashboard. This helps accounting teams review imported sales-related records without missing entries due to how they were categorized during import.
Original PR description
**PROBLEM** When importing a FEC files, moves are created with the `move_type` `entry`. They don't appear in the action of the journal of type `sale` when clicking on the dashboard. **STEP TO REPRODUCE** 1. on a local database install `l10n_fr_fec_import` (you need to import a FEC file given by our client, dont do it on the runbot please !) 2. select the french demo company 3. import the FEC file (accounting/settings/import a file) (for file, see [ticket](https://www.odoo.com/odoo/project/49/tasks/4848763) ) 4. goes in the dashboard, and click on the `Ventes Marchandises` journal. 5. notice the entries does not appear in the action. **CAUSE** When importing a FEC file, all moves are created with the `entry`. The domain for `sale` journal doesn't include the move of type `entry`. **FIX** Adding `entry` in the `sale` journal domain. opw-4848763
Fixes an Accounting issue where creating an analytic item linked to a zero-value invoice could crash the system. This helps users handle no-cost or fully balanced invoices without interruption.
Original PR description
The system will crash with error when try to create a analytic item. **Steps to Produce:-** 1. Install the `Accounting` module with demo data. 2. Go to `Settings > enable Analytic Accounting`. 3.…
The system will crash with error when try to create a analytic item. **Steps to Produce:-** 1. Install the `Accounting` module with demo data. 2. Go to `Settings > enable Analytic Accounting`. 3. Navigate to `Accounting > Customers > Invoices`. 4. Create a new invoice with total amount = 0 and confirm it. 5. Go to Accounting > Accounting > Transactions > Analytic Items. 6. Create a new Analytic Item and: - Set a value in the `Project` field. - Under the `Accounting` section, select the `Journal Item` linked to the last created 0-amount invoice and save. **Error:-** `ZeroDivisionError: float division by zero` **Cause:-** - At [1], when `line.balance` is 0.0 (for example, when a journal item is defined with a total of 0.0), the system raises an error. **Solution:-** - Added a condition to compute only when line.balance exists; otherwise,set the value to 100. [1]: https://github.com/odoo/odoo/blob/dff2423ac320fdb97d6bf1f106dc84be1d71cac2/addons/account/models/account_move_line.py#L3248-L3251 **sentry-6844926153** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a Spanish Point of Sale issue where completing an order could show a blank screen if the simplified invoice partner had been archived. Cashiers can now validate sales without disruption, reducing confusion and failed checkout flows.
Original PR description
Steps to Reproduce: -------------------- - Install the l10n_es_pos module in version 18.0. - Navigate to Contacts. - Search for Simplified Invoice Partner (ES) and archive the record. - Open the…
Steps to Reproduce: -------------------- - Install the l10n_es_pos module in version 18.0. - Navigate to Contacts. - Search for Simplified Invoice Partner (ES) and archive the record. - Open the Point of Sale (POS) and proceed to place an order. - Select a product. - Proceed to the payment screen. - Choose a payment method and click Validate. Issue: --------------------- In version 18.0, when the user proceeds with placing an order, a blank screen appears without any error message, leading to confusion for the customer. This issue occurs because during the [pos_load_data](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/models/pos_session.py#L181) process, while preparing the pos.config, the `simplified_partner_id` is fetched. However, the corresponding `res.partner` record is not included during the preparation of the `res.partner` model data, as the record is archived. As a result, when the system attempts to link the related partner record to `pos.config.simplified_partner_id` on the [JavaScript side](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1063-L1131 ), [ref](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/point_of_sale/static/src/app/models/related_models.js#L1114) the simplified_partner_id remains undefined. This eventually leads to an error when attempting to access [simplified_partner_id.id](https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/l10n_es_pos/static/src/overrides/models/pos_store.js#L8) and will lead to the blanck screen video ref: https://drive.google.com/file/d/1oG6bBIWxhlvnJAgj22hEVtlW0hr8_1eU/view?usp=sharing ```text Other Approaches: - We can override the _load_pos_data method and append the simplified partner to ensure it's included during the data loading process. - Instead of showing a blank screen, we can display an alert message informing the customer to unarchive the simplified partner and proceed with the flow. `I’m open to any suggestions or alternative approaches that would be the best way to handle this.` ``` OPW: 4953896 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
When loading older messages fails once, the conversation no longer keeps showing an error after a later successful retry. This prevents users from seeing a stale failure message when their messages have already loaded correctly.
Original PR description
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch…
**Description of the issue this PR addresses:** When a thread fails to fetch its messages (e.g., due to a network error), the `hasLoadingFailed` flag is set to `true`. However, even if the next fetch attempt succeeds, the flag is not reset. As a result, the UI may continue to show an error state even though the data has successfully loaded. **Steps to Reproduce:** - Open a thread with many messages. - Go offline. - Scroll up to load older messages → failure message appears. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> - Go back online and click Retry → messages load successfully. - Scroll again → failure message still appears, even though you’re online. - <img width="311" height="68" alt="image" src="https://github.com/user-attachments/assets/e18832cb-5d37-4add-a126-fdc301131721" /> **Current behavior before PR:** After a failed attempt to fetch messages in a thread, the `hasLoadingFailed` flag remains set to `true`. Even if the user goes back online and the subsequent fetch succeeds, the UI continues to show a failure state. **Desired behavior after PR is merged:** After a successful fetch of a thread’s messages, the `hasLoadingFailed` flag is reset to `false`, ensuring the UI no longer shows a failure state once the data has been correctly loaded. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This pull request brings a broad set of maintenance updates across Odoo 18, including fixes for payments, sequence numbering, calendar reminders, inventory manufacturing flows, eCommerce access, email UI behavior, and localization compliance. These changes reduce user-facing errors, improve regulatory accuracy, and keep translations current for international users.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a payment memo is changed, the related accounting entry reference is now updated to match. This prevents inconsistent payment and accounting records, reducing confusion during reconciliation or audits.
Original PR description
Issue: In previous versions, the memo field of account payments and ref field of account move were related Now that payments do not required to have generated account move's when the memo is updated the ref remains unchanged. Purpose of this PR: To update the account move ref when the payment memo is updated. Steps to Reproduce on Runbot: install accounting go to bank account and assign outstanding accounts for manual payment methods create a payment -- a related account move should be created update the memo on the payment -- the ref on the related account move is unchanged. opw-4989260 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Live chat chatbots now use the intended step order to decide whether a visitor is returning to a saved conversation. This prevents chatbot flows from unexpectedly restarting when steps were created in one order and later rearranged, improving continuity for website visitors.
Original PR description
before this commit, `isRestoringSavedState` was computed by comparing chatbotStep IDs instead of the sequence number. This is an unreliable method that could lead to unexpected restart of the chatbot flow if the user created their steps in a certain order then swapped that order around. Besides, the field `sequence` is precisely meant to track this state. This commit adds `sequence` and computes the `isRestoringSavedState` based on that sequence. opw-4858896 Forward-Port-Of: odoo/odoo#218372
The accounting setup now ignores localization chart templates from modules that are not currently installable. This prevents unnecessary error logs when a custom localization module is present but not yet ready to be installed or upgraded.
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
This fix prevents the mail module from failing when it encounters an empty value while preparing email records. It improves reliability by safely ignoring invalid empty entries before continuing processing.
Original PR description
Browse breaks when given a bool, so the solution is to filter the list from false values before browsing --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Withholding tax entries now use the invoice line account when no specific tax account is defined, preventing amounts from being posted to the wrong default withholding account. Payment and tax selection rules were also tightened so users can only choose valid withholding taxes, improving accounting accuracy.
Original PR description
**FIX - 1 : rectify default account on tax line** Before this **PR**: The Withholding Tax (WTH) base account, if set on the company, was being used as the default account. This account overrode the…
**FIX - 1 : rectify default account on tax line** Before this **PR**: The Withholding Tax (WTH) base account, if set on the company, was being used as the default account. This account overrode the expected behavior and was applied not just to the base and counterpart lines, but also to the tax line, when the tax repartition line had no account defined. After this **PR**: If the tax repartition line has no account set, the system now uses the account from the invoice line (typically an income or expense account) instead of the WTH base account. Additionally, in cases where withholding is added directly on a payment or payment registration, a constraint has been added on the tax_id field in account_withholding_line to prevent users from selecting a tax that lacks an account on its repartition line. **Technical background**: Previously, when a WTH base account was available, it was used in the creation of withholding lines. These lines, created during payment processing via _prepare_withholding_amls_create_values, inherited the WTH base account on the base line. Later, _add_accounting_data_in_base_lines_tax_details used this base account for tax line creation if the tax lacked its own repartition line account, resulting in incorrect account assignment. **Solution**: Always use the invoice line’s account (e.g., income/expense) when creating withholding lines. This ensures that the tax lines use the appropriate account. If a WTH base account is configured, it will only be applied to the base and base counterpart lines, not the tax lines in the _prepare_withholding_amls_create_values. **FIX - 2 : rectify domain on tax_id** With this commit, the domain for account_id in the account_withholding_line model correctly includes group taxes that contain at least one withholding tax. **task**-4883286
Users in secondary companies can now save Documents settings even when no Sign folder has been configured for that company. This removes an unnecessary validation error that blocked changes such as choosing a spreadsheets workspace.
Original PR description
**Steps to reproduce** - On a fresh DB, have multiple companies - Install documents_sign - With a company other than the main one, go to Settings > Documents > try to change a setting (e.g. Spreadsheets Workspace) - Error: "Invalid fields: Sign Base Folder" **Cause** Issue after commit https://github.com/odoo/enterprise/commit/a47cad41b1537b0c90b6a0ab9bf498a160f88b72 The `documents_sign_folder_id` is only set on the main company and since it is required on the view, saving the view is impossible if the field is invisible. **Change** Since the folder serves no purpose, make it non required in the view. opw-5048447
The bank reconciliation report now excludes exchange rate adjustment entries that do not represent real bank inflows or outflows. This prevents currency revaluation differences from being incorrectly shown under miscellaneous operations, giving finance teams a clearer reconciliation view.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#93999
This update adds automated coverage for the Spanish Modelo 130 report to help ensure it stays accurate in future updates. It reduces the risk of regressions in a tax reporting area without changing day-to-day user workflows.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#90044
Users can now add approvers to their own approval requests without encountering an access error. The update also prevents request owners from changing or deleting approvers when they should not have that permission, helping keep approval flows controlled.
Original PR description
Fixed an issue happening when trying to add approvers to one's own request, and remove their ability to delete approvers from the request Task-4897775 Forward-Port-Of: odoo/enterprise#92309
This fix prevents Uruguay electronic invoice generation from failing when an invoice line has no product and no line description. In those cases, the system now safely sends a fallback value instead of blocking CFE document creation.
Original PR description
This pull request makes a minor adjustment to the logic for extracting item names and descriptions in the `_l10n_uy_edi_get_line_nom_and_desc` method. The change ensures that the presence of `aml.name` (the line description) is checked directly, rather than relying on the truthiness of the entire `aml` object. Before this PR, if the aml of an invoice only have the `account_id` field filled and no `product_id`, the `_l10n_uy_edi_get_line_nom_and_desc` will raise an error message like `TypeError: 'bool' object is not subscriptable` when trying to create de CFE document. <img width="1254" height="828" alt="image" src="https://github.com/user-attachments/assets/eaadad4c-46c3-4e3b-be52-9fcd146f2c22" /> <img width="1526" height="795" alt="image" src="https://github.com/user-attachments/assets/1b831f41-9774-4ed5-9a9d-9777ee0633e9" /> With this fix, we ensure there is a name to grab or the '-' will be send instead.
Studio exports no longer fail when they include binary fields that are not stored as attachments. This prevents an error during export and helps users reliably extract their Studio data.
Original PR description
**Before:** Attempting to export non-attachment binary fields using the `Studio Export` would cause a traceback. **After:** Non-attachment binary fields can now be successfully exported from `Studio` without error. task-4888937
Fixed an issue where users could see an error after opening an embedded list view from a Knowledge article and then returning to edit the article. This prevents interrupted editing and helps keep Knowledge article content stable after using embedded views.
Original PR description
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical…
Steps to reproduce =================== 1. Insert any list view in the knowledge article. 2. Click on open view from the article. 3. Come back and click edit. -> Traceback occurs Technical ============= When we open a view from an embedded view in the article, we add `orderBy` from the action context to the action props if it exists. As the action prop is initialized and assigned directly from `embeddedState.additionalViewProps` without copying, it mutates the original object, changing the `data-embedded-props` attribute in the DOM and marking the body of the article as unsaved from `StateManager.changeState`. The action continues, and the action service commits those unsaved changes to the article. Once it is saved and the action is executed, when we get back to the article and click on edit, we check for `additionalViewProps` to be undefined/empty for all other views except calendar. As the DOM already has saved data in attributes, we get `orderBy` in `additionalViewProps`, and thus a manual error is thrown in the `editView` function. After this commit =============== Clone `additionalViewProps` when preparing the view action props. Task-4921282
The Swiss financial reports now show previous-year unallocated profit and loss using the correct period. The balance sheet also includes clearer lines for current-year retained and allocated earnings, helping users review annual results accurately.
Original PR description
Before this commit, `Previous Year unallocated profit and loss` was showing wrong amount. With this commit, we adapt this line (change period of one of its expression) and we add two new lines to reflect the actual year earnings, retained and allocated. Steps, with fresh db: - 1 invoice confirmed in the past year for 1000 - Create the carryforward move (1000 debit for 999 account, and 1000 credit for 2979 account) - Go to balance sheet, set date as 'End of last fiscal year' -> See 'Previous Years Unallocated Earnings` showing -1000 opw-4054341
German DATEV exports now correctly identify the main account when a POS session includes both sales and refunds with different tax rates. This prevents missing accounting data in affected export entries and helps ensure smoother compliance 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 Documents app Kanban view no longer shows an unnecessary second scrollbar. This makes browsing documents cleaner and easier for users by removing a confusing visual glitch.
Original PR description
This commit fix the useless double scroll bar in kanban view. Task-4844661
Fixed an issue where clicking the dashboard header after changing the Publish toggle could accidentally reverse the publish setting. The publish control now responds only to the checkbox or its label, making dashboard editing more predictable for users.
Original PR description
**Steps to reproduce:** - Open a dashboard in edit mode. - Click the “Publish” toggle to change its state. - Click elsewhere on the header (outside the toggle). → The publish state flips back unexpectedly. **Before this PR:** The wrapper container (.o_sp_publish_dashboard) had a click handler, causing clicks on the header to re-toggle the publish state. The CheckBox was rendered with a no-op onChange, so both elements competed for control. **After this PR:** Interaction is handled exclusively by the CheckBox component. toggleDashboardPublished is bound directly to its onChange. Clicking the label text now correctly toggles the checkbox and publish state. Container clicks outside the checkbox no longer affect the state. Task: [5062368](https://www.odoo.com/odoo/project/2328/tasks/5062368)
Belgian payroll work entry UCM codes now preserve trailing spaces and are padded when needed to meet the required three-character format. This prevents valid UCM codes such as "PR " from being shortened incorrectly, helping payroll configuration match UCM specifications.
Original PR description
#### Issue: - UCM work entry code should be 3 characters long and allow spaces to get this length #### Step to reproduce: - In a Belgian company - Go to Payroll > Settings > Work Entry Types > New - Add a name - Add a Payroll Code - In the `Country` field fill Belgium - In the field `UCM Code` enter "PR " - Select another field - Select `UCM Code` again #### Current behavior: - The field `UCM Code` was updated to "PR" #### Expected behavior: - The field should stay to "PR " #### Solution: - Don't trim the field and add a spaces if needed opw-5014372
The Belgian salary configurator now prevents employees from entering fuel card amounts when they have selected a reimbursed private bike option. This avoids incompatible benefits being combined and keeps salary configurations compliant with the intended rules.
Original PR description
The Belgian salary configurator allows employees to declare a private bike cost. When the "Private Bike" option is checked and its reimbursement value is greater than zero, the fuel card inputs must be reset to 0 and disabled. task-5062963 Forward-Port-Of: odoo/enterprise#93884
The German tax report XML export now keeps decimal amounts with a period instead of changing them to a comma. This prevents Elster from ignoring VAT amounts during submission, reducing the risk of incomplete German VAT returns.
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 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#93623
The Accounting reconciliation screen now correctly filters out entries that have already been reconciled. This helps accounting users review only the remaining items that still need attention, reducing confusion and manual checking.
Original PR description
**Issue:** 1. When we go to Accounting. 2. Reconcile and apply the filter "Unreconciled", it does not work as expected. **Steps to reproduce the issue:** 1. Go to Accounting → Create an invoice and confirm it 2. Create a payment for the invoice. 3. Go to the Dashboard → Bank Reconciliation 4. Reconcile the payment with the created invoice. 5. Go to Accounting → Reconcile to verify the reconciliation. 6. Apply the filter "Unreconciled" 7. The filter shows records that are already reconciled. **Before Fix:** <img width="1917" height="956" alt="Reconciled" src="https://github.com/user-attachments/assets/a1d99c6f-1603-456d-879f-e5a29bc87349" /> **After Fix:** <img width="1916" height="953" alt="reconciled_after" src="https://github.com/user-attachments/assets/fd252e45-2ad6-430c-9c31-632bce657d83" /> **Desired behavior after PR is merged:** - When we apply the Unreconciled filter, it should return only unreconciled records. OPW : 4904321 UPG : 3112101
The WhatsApp integration now uses the latest supported Meta Graph API version. This helps prevent future disruptions caused by automatic API version changes and keeps messaging functionality stable for users.
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#93170