Thursday, January 29, 2026
12 changes · 18.0
Resolved issues and error corrections
This update corrects a technical issue preventing invoices from successfully validating with DIAN, Colombia's tax authority. The fix involves updating a specific tag format in invoices to match DIAN's requirements, ensuring accurate and compliant invoice submissions. This resolves a validation error and avoids potential delays in tax reporting.
Original PR description
Problem: When validating invoices with DIAN, an error is received. Cause: Incorrect tags are being used in the invoices. These tags are checked when invoices are validated with DIAN. Solution: Use the correct tags in the invoices. schemeName should be used instead of scheme_name. Steps to reproduce: - Install l10n_co_dian module - Choose a Colombian company - Activate DIAN service in Settings - Create an invoice and send it while making sure the DIAN checkbox is ticked - Download the generated zip file and uncompress - Open the XML file and check for scheme_name. It should be replaced by schemeName. opw-5829958
This update fixes a minor issue in the subscription payment process. Previously, a payment link was always displayed, even when the subscription was expired and certain products had been archived, leading to a confusing user experience. Now, the 'Pay Now' link only appears when the advance payment section is visible, streamlining the payment flow for users.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived) Forward-Port-Of: odoo/enterprise#105480
This update ensures that text continues to appear correctly in Odoo views after a field is removed due to security restrictions. Previously, removing a field caused inconsistencies in the view's layout. This change maintains a consistent and professional appearance for all users.
Original PR description
In a view, if a field is removed due to security access restrictions, the text that follows it is not preserved. This leads to inconsistencies in the view. opw-5798852 Forward-Port-Of: odoo/odoo#245855
This update fixes a potential issue where users could inadvertently set non-stored models as default values for model pages, leading to errors. The change now prevents this by raising a validation error if a non-stored model is selected, ensuring data integrity and preventing unexpected behavior.
Original PR description
Steps to Reproduce: 1) Install the following modules: website, stock_account, web_studio. 2) On the homepage, create a new custom app using Studio. 3) Fill in these details: - App Name: Test App - In the `Create your First Menu section`, select 'Existing Model', choose 'Stock Quantity Report' to link this app, and click Create your App. 4) Navigate to 'Model Pages' and create a new model page and click on 'go to website' magic button. Before this commit: By following the above steps, User can set non-stored models as default model. Due to which on creating a Model Page the dafault value for 'Exposed Model' will be set as default model(e.g. Stock Quantity Report) and user can save it later on which leads to an issue. After this commit: If 'Exposed Model' is set to a non-stored model ValidationError will be raised. Related Enterprise PR: https://github.com/odoo/enterprise/pull/94286 sentry-6842596566
This update resolves an error that occurred when creating website pages linked to certain non-stored Odoo models (like reports). The fix prevents Odoo from attempting to access fields that don't exist in these models, ensuring website page functionality works correctly. This improves stability and usability for users creating custom website content.
Original PR description
Currently, an error occurs when a user creates a 'Model Page', which is referring to a non-stored model and trying to access it through website view. Steps to Reproduce: - Install stock, website and…
Currently, an error occurs when a user creates a 'Model Page', which is referring to a non-stored model and trying to access it through website view. Steps to Reproduce: - Install stock, website and web_studio modules. - Open Inventory and turn on studio mode. - Navigate to model pages. - Create a new model page with the exposed model as 'Stock Quantity Report'. - Save and click on the Website smart button and you will get the error. Error: `ValueError: Invalid field 'create_date' on model 'report.stock.quantity'` Root Cause: Odoo Studio allows creating website pages for any model, including non-stored models (`_auto = False`) such as `report.stock.quantity`. When a user creates a `Model Page` with such a model, Odoo attempts to fetch records from the database and sort them by `create_date` as shown at [1]. Since these models do not have a database table, the `create_date` field does not exist, causing the error. Fix: Exclude non-stored models from the model selection for Model Pages. [1]: https://github.com/odoo/odoo/blob/ce2d134d3e8e5c0d96529c1d0490f1e0c5e28294/addons/website/controllers/model_page.py#L77 Related Community PR: https://github.com/odoo/odoo/pull/226774 sentry-6842596566
This update resolves an issue where dynamic product snippets would display a horizontal scroll when the content width was set to 'max'. The fix repositions the navigation buttons to prevent this scrolling behavior, ensuring a consistent and user-friendly experience on larger devices.
Original PR description
Steps to reproduce: 1. Drag and drop the dynamic products snippet. 2. Select it and change the content width to **max**. Issue: When the content width is set to **max**, an unnecessary horizontal scroll appears. Reason: The issue occurs because the `previous` and `next` navigation buttons were not properly positioned. Fix: For devices larger than "mobile", the `previous` and `next` buttons are re-positioned, horizontally inward by "**50%**" of their own width with the help of `transform` property. This keeps the controls within the visible area and prevents horizontal scrolling. task-5090468 Before: <img width="1915" height="966" alt="image" src="https://github.com/user-attachments/assets/0c20d0b6-32cc-477b-8403-55bb0d372d8d" /> After: <img width="1920" height="963" alt="image" src="https://github.com/user-attachments/assets/4194b0f1-f3ad-4818-aa6f-2fda4561d2c7" />
A bug was causing the input field for campaign tests to disappear when cleared, requiring users to close and reopen the dialog. This fix resolves the issue by ensuring the input field remains visible, improving the user experience for campaign testing. The scope was limited to marketing automation due to prioritization.
Original PR description
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: -…
Steps to reproduce: 1. Install `marketing_automation` 2. Create a campaign with activity and click on `Launch a test` button 3. Clear the input field and then click outside the input area Issue: - The input area has disappeared. Now, the only way to get it back is by closing the dialog and reopening it Cause: - Field `resource_ref` uses `hide_model: True`, and when cleared, the widget has no value and no model selector to determine the target model because of the function `getRelation` that now returns `undefined`, by this XML fails to render the `<Many2OneField/>` https://github.com/odoo/odoo/blob/7680b83501cef18362be38f90715d824f2bf9cd6/addons/web/static/src/views/fields/reference/reference_field.js#L107-L119 Solution: - Add `model_field: model_id` option to the view so the widget can resolve the model from the `model_id` field even when input is empty Note: - This behavior also occurs in other places. After discussion with the framework team, we agreed to keep the scope of this PR limited to marketing_automation, as this is not a priority issue. A broader fix can be addressed in the master if needed. opw-5473320
This update addresses a small technical issue where a missing space in a route caused a problem with the account online synchronization process. This fix ensures the synchronization feature functions correctly, preventing potential disruptions to data synchronization.
Original PR description
During this forward port: https://github.com/odoo/enterprise/commit/a5b9372ca0b23151046c14c9a8ead0ed9cd46b80 there was a missing space in the route. no task id
This update resolves a visual issue where carousel previews appeared too tall in Firefox. The fix adjusts the preview height, ensuring consistent and accurate display of carousel snippets for users. This improves the user experience and prevents potential confusion.
Original PR description
Steps to reproduce (only with Firefox): - Open the snippet dialog. - Issue: The carousel snippets are too tall. Bug introduced by this commit [1] [1]: https://github.com/odoo/odoo/commit/78d33cf8b475f891dd95bec1b0c058446538824a task-5156137
This update resolves an issue where the FAIA report incorrectly classified partners as suppliers. The change allows partners to be recognized as both customers and suppliers, addressing a discrepancy caused by credit notes. This ensures accurate reporting of financial balances within the SAFT report.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create…
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer. This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e opw-5360924 Forward-Port-Of: odoo/enterprise#100749
This update fixes a validation error preventing employees from requesting paid time off when using a 2-week calendar schedule. The issue stemmed from a formatting element within the calendar that was incorrectly calculating start and end dates. This change ensures accurate PTO requests are processed for all calendar types.
Original PR description
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select…
Steps to reproduce: - Choose France as the company location, and download "France - Work Entries Time Off" module. - From Employees > Configuration > Settings > French Time Off Localization, select Paid time Off. - Create a new employee and a new contract (in running state) for that employee that starts on 01/01/2025. - While in the contract screen, create a new schedule that has 2 weeks calendar and Europe/Paris timezone. - From Time Off > Management > Allocations, allocate 1+ paid time off days for the newly created employee that's valid from 01/01/2025. - From the employee's profile > Time Off, try to take a Monday off. Issue: - The user gets a Validation error stating that the "start date" is later than the "end date". Fix: - In a 2 weeks calendar, there are 2 lines that are there to separate the first week from the second week (for aesthetic purposes). These lines have "hour_from" and "hour_to" = 0, which are taken into account when calulating the minimum hour to start the day off. - Add a check to remove lines from calendar that are just there for display purposes. opw-5387347
This update fixes an issue where product names weren't consistently displayed in the correct language based on the user's current language setting. Previously, repeated access to the product name within a method would default to the initial language, even with a different language context. Now, the system always uses the specified language context when calculating the product name, ensuring accurate display for all users.
Original PR description
Description of the issue/feature this PR addresses: Compute of display_name in different languages that can be returned incorrect Current behavior before PR: When accessing two times in the same method the display_name of a configured product but the second time having a .with_context(lang=lang) other than the previous language, the returned display name will not be in the specified language as the cached value will be returned. Desired behavior after PR is merged: _compute_display_name should always take into account a change of language in context when the value is accessed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr