Thursday, October 16, 2025
20 changes · saas-18.4
Resolved issues and error corrections
Portal users opening shared project tasks will no longer see a chat expand option that caused an error. This prevents a crash-like experience and keeps the project sharing chat limited to actions supported in the portal.
Original PR description
Steps to reproduce: === - Create a project. - Share the project with access to edit rights to the portal user. - Log in as the portal user. - Open the shared project and then open a task. - Click on the expand button in the chat. Issue: === A traceback occurs when trying to expand the chatter in a project sharing task. Cause: === `inFrontendPortalChatter` not being set in `useSubEnv` is the reason for button appearance, and we don't have the necessary composer for it to render in the project sharing bundle. Fix: === Define missing `inFrontendPortalChatter` to hide the expand chatter composer action as it was not meant to be available in the portal/front-end. task-5049129 Forward-Port-Of: odoo/odoo#231360
Failed email replies for accounting journal aliases now use the company linked to that alias instead of defaulting to the main company. This prevents customers or senders from seeing the wrong company name or email address in bounce messages when working with multiple companies.
Original PR description
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an…
A bounce email was introduced in https://github.com/odoo/odoo/pull/168506 , i.e. if an email without an attachment is sent to an incoming email alias for a journal, it will be bounced with an corresponding email template. But as is, the usage of `'company_email': self.env.company.email` and `'company_name': self.env.company.name` will default to the "main" company (id 1 usually), as during the message routing, that will be the default company in `env`. This means, that if you have an journal email alias in company B, the email will still render the information of the main company A. ## Proposed fix: When a journal email alias is created in a standard way, it should have a key:value pair for 'company_id' in the `alias_defaults` field. We change the routing check logic so that it will try to fetch that value, while defaulting to the main company if there is no explicit company `company_id` key. This should ensure that the mail gateway failed email renders preferentially renders the company information of the company the mail alias (and accounting journal) belongs to. OPW-5132806 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231436
Users now receive a clear validation message when entering a check number that is too large for a Bank Journal. This prevents a confusing technical error and helps accounting users correct the value before saving.
Original PR description
**Issue** When trying to set a very large value as *Next Check Number* in a Bank Journal, Odoo raises a low-level `RPC_ERROR` caused by a PostgreSQL `integer out of range` error. This results in a technical traceback instead of a clear message to the user. **Steps to Reproduce** 1. Go to *Accounting > Configuration > Journals* 2. Open the Bank Journal 3. Go to the *Outgoing Payments* tab 4. Enable *Manual Numbering* 5. Set *Next Check Number* to `2147483648` **Root Cause** The field `ir.sequence.number_next` is stored as an integer in the ORM. Any value greater than `2,147,483,647` (max signed 32-bit integer) causes PostgreSQL to raise an overflow error when saving. Since the error occurs deep in the ORM write call, the user only sees a generic RPC error without explanation. Opw-5042096 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225103
This fixes an issue that prevented users or administrators from creating certain related one-to-many fields when no inverse field was available. The change helps configuration flows work as expected and reduces setup blockers in the base model framework.
Original PR description
…n_field Before this commit, it was not possible to create a related one2many without a relation_field (inverse) However, the relation_field of a relation cannot be the one of the original field (because it doesn't exist on the current model) After this commit, this flow works. opw-5155440 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#231434 Forward-Port-Of: odoo/odoo#231187
This fix prevents an error when users create certain related customer contact fields in Studio, such as linking a sales order to a customer's child contacts. The system now avoids saving an invalid relationship setting, improving reliability during form updates.
Original PR description
On sale order, create a related field to res_partner.child_ids Before this commit, the related field is not stored but has a relation_field to parent_id (res.partner) During an onchange (outside of studio), this will crash. After this commit, we unset relation_field in this case as it doesn't make sense (the relation_field should reference a res.partner field, not a field presetn in the current model) opw-5155440 Forward-Port-Of: odoo/enterprise#97107 Forward-Port-Of: odoo/enterprise#96950
Fixed an issue where dropdown menus could appear slightly misplaced when their content was wider than the button opening them. This improves the visual consistency and usability of selection menus in the web interface.
Original PR description
This commit fixes the position of the SelectMenu, that was not aligned properly when the content of the menu is larger than the toggler width before applying any maxWidth. Because the 'fit' variant sets the same width to the popper by default, and the code was applying this width after the computation of the position of the popper, the menu was displaced. Now, the width is applied before positioning the menu, which then computes accordingly. A test has been added as well. task-4674144 Forward-Port-Of: odoo/odoo#230983 Forward-Port-Of: odoo/odoo#224568
A correction was made to how financial reports calculate certain values, preventing incorrect internal handling during report generation. This helps ensure accounting reports remain reliable for users without changing how they interact with the system.
Original PR description
Forward-Port-Of: odoo/enterprise#97144
Fixed an issue in the HTML editor where changing text color near an icon could accidentally recolor a larger surrounding section. This helps users format content more precisely and avoids unintended visual changes in edited pages or documents.
Original PR description
After this [commit], we'd have an issue when we tried to change a color and there was an `fa` icon next to our selection. Instead of changing the color of only the selection it would change it for the closest element with `color`, `background-color`, or `background-image` style properties. To reproduce the bug: - Set selection on an element that has a color style property on its parent, and the parent has .fa icon but not directly on our element - Try to change its color => Color of the whole parent changes task-5107147 [commit]: https://github.com/odoo/odoo/commit/927f4b973932d14961c148e13473017651a60dc0 Forward-Port-Of: odoo/odoo#229311
This fix prevents Odoo Discuss calls from crashing when a peer-to-peer connection offer is processed after a delay. It improves call reliability by safely handling cases where the connection participant is no longer available when the event completes.
Original PR description
Before this commit, since https://github.com/odoo/odoo/pull/205198, the handling of an offer can be arbitrarily delayed by the `acceptOffer` callback. This could lead to a traceback when the reference to `peer` is stale by the time the event is handled. Forward-Port-Of: odoo/odoo#231620
Project calendar views now apply the correct filtering when finding tasks that can be planned. This helps ensure users see the right tasks in scheduling views and avoids inappropriate tasks appearing in planning workflows.
Original PR description
This commit overrides a hook created in related Community PR to add a condition in the domain to fetch tasks to plan inside for task calendar views.
Romanian eTransport exports now use the EU VAT-standard country code for Greece, changing it from GR to EL where required. This helps prevent validation errors when submitting transport documents and keeps partner and transporter country data consistent.
Original PR description
Added a mapping for EU VAT country codes to ensure that the VAT prefix aligns with EU standards (e.g., 'GR' -> 'EL') in EDI exports. ## Description of the issue/feature this PR addresses: This PR…
Added a mapping for EU VAT country codes to ensure that the VAT prefix aligns with EU standards (e.g., 'GR' -> 'EL') in EDI exports. ## Description of the issue/feature this PR addresses: This PR adds country code mapping functionality to ensure compatibility with the format required by the Romanian eTransport system. Specifically, it adds the conversion of the country code "GR" (Greece) to "EL" according to European VAT standards and applies this mapping to relevant fields in transport documents. ## Current behavior before PR: Before this PR, the country code for Greece was sent as "GR" to the eTransport system, which could cause validation errors because in European VAT systems, Greece is identified by the code "EL". Also, there was no consistent mapping for country codes in different parts of the system. ## Desired behavior after PR is merged: After implementing this PR, country codes will be correctly mapped to comply with European VAT standards, especially the conversion of "GR" to "EL" for Greece. This ensures that documents sent through eTransport contain the correct country codes and will pass system validations. The mapping is applied to country codes for both commercial partners and transporters. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216122 Forward-Port-Of: odoo/odoo#214621
When users view more themes during website setup, Odoo now shows a fullscreen loading screen until the additional themes finish loading. This prevents users from accidentally selecting an existing theme while the theme list is still being updated.
Original PR description
Steps to reproduce: 1. Create a new website and proceed to the theme configuration step. 2. Click on View More Themes. -> You’ll notice a loading effect on the button, but the existing themes remain selectable. Before this commit: Users could still select existing themes while additional themes were being loaded. After this commit: A fullscreen loader is displayed while loading more themes via the View More Themes button, preventing any unintended interactions. task-4661292 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#230557
The checkout progress steps are now translated correctly when shoppers use the website in a language other than English. This improves the checkout experience for multilingual websites and avoids confusing mixed-language pages.
Original PR description
Versions -------- - saas-18.3+ Steps ----- 1. Have a website; 2. enable a new language (other than English); 3. use website in this language; 4. go to checkout. Issue ----- The checkout steps on the top-left aren't translated. Cause ----- Commit dbd22d93183f2 added the `website.checkout.step` model. Like `website.menu`, they have a default record that gets set on initialization, which is then gets used to create a new record per website. The issue is that when enabling a new language, it only translates the default records. The records that are website-specific remain unchanged. Solution -------- Because they function the same we as `website.menu`, we can use the same approach that was taken to translate website menus, and add a `_load_module_terms` override to `ir.module.module`, constructing a SQL query that copies the translations from the default records to the website-specific records. opw-4985676 Forward-Port-Of: odoo/odoo#223019
Users can now open import screens that offer more than one sample template without the page crashing. The template buttons are also spaced more cleanly, making the import experience smoother.
Original PR description
Import templates are defined on models to allow developpers to provide
sample import files to users. These templates are fetched by the client
as an array of objects of the form {label: string, template: string},
where label is the label to display and template the URL of the file.
The iteration on `importTemplates` goes through this list, and if more
than one element is present in it, the t-key for both elements will be
the same (`[[object Object]]`), leading to a crash of the client
action's template.
This commit uses the 'template' url as the key, as it should be unique
(the label is less trustworthy, as it is translatable).
It also slightly changes the styling, as having an mb32 between multiple
buttons looked rather bad.
Forward-Port-Of: odoo/odoo#231521
Forward-Port-Of: odoo/odoo#231407Employees and HR teams can once again see weekends and public holidays that occurred before the start date of the current contract. The fix uses past expired contracts to provide accurate working-time information while still excluding draft contracts that should not count.
Original PR description
Since changes made in https://github.com/odoo/odoo/pull/212959, we don't see anymore the week-end and banck holidays before the start date of your current contract. As the goal of the initial commit was to prevent to use the contracts in state 'new', we add the contracts 'exppired' that are contracts of the past that really give information of the working hours. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231400
Website form fields now retain their spacing offset when display settings such as label position or descriptions are adjusted or previewed. This prevents accidental layout changes and saves users from having to reapply formatting while editing forms.
Original PR description
Before this commit, changing display parameters of a field (label position, description, etc.) would remove the offset already added. It would require to add them again if a change was made on the display, even if the mouse just hovered the buttons. This commit solves the issue. Steps to reproduce the bug: - Add a form snippet - Add an offset to a field - In the snippet customization, hover over the label position (The offset was removed for good) task-3675509 Forward-Port-Of: odoo/odoo#231297 Forward-Port-Of: odoo/odoo#181344
The Point of Sale product information popup now shows inventory for the exact product variant selected, rather than potentially using the broader product template. This helps store staff see accurate stock availability when selling products with multiple variants.
Original PR description
Before this commit, when a product template had several variants, opening the product info while a specific variant was selected would not display the inventory information of the selected variant. opw-5161698 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231266
Tooltips in Live Chat, Discuss, Point of Sale, and web interface elements are now included in the normal translation process. This fixes cases where helpful hover text could remain untranslated, improving consistency for users working in different languages.
Original PR description
Unless you tell Owl to do so, custom attributes like data-tooltip aren't translated. This commit adds the data-tooltip attribute to the list of translated attributes when missing. *: im_livechat, mail, point_of_sale Forward-Port-Of: odoo/odoo#231541 Forward-Port-Of: odoo/odoo#231006
This update fixes an issue that could cause an error when opening Studio from the activity display in Point of Sale preparation displays. It helps keep configuration workflows reliable and avoids disruption from an internal temporary record reference.
Original PR description
This commit prevents a NewId to be used in a domain when opening studio from the activity display. runbot error #233396 Forward-Port-Of: odoo/enterprise#97332
Features or functions removed from Odoo
This removes leftover files from a previously deleted HR contract spreadsheet dashboard module. The cleanup prevents an incomplete, unusable module directory from lingering after translation exports.
Original PR description
Module was originally removed by 46052c4bc5ad1bd2549a6125202e0671b56beac8 but was necromantized back into unlife by the translations export 0c1874473050f6e3cb68601737e3b4216aee5cad, being revived as a directory with a data file and a translation file but no manifest.