Daily updates from Odoo
Monday, November 3, 2025
141 changes
16 changes
Resolved issues and error corrections
This update prevents text from being highlighted twice when an existing highlight is already present on a parent element. It makes editing more consistent and avoids visual duplication that could confuse users.
Original PR description
Problem: When a text highlight is applied on a node that has an ancestor with the same text highlighted, both highlights remain. The ancestor's highlight should be removed before applying the new one. Cause: When applying highlight, it is done on the text node (leaf node). However, one of the ancestors might already have the highlight applied. This is not removed, leading to duplicate highlights. Solution: When applying the highlight, check if an ancestor has the same text and highlight style applied. If so, remove it before applying the new highlight. Steps to reproduce: 1. Add text "ABC". 2. Apply text highlight on "B". 3. Apply animation on "B". 4. Apply text highlight on "ABC". 5. In the DOM, "B" has two highlights (visually noticeable). opw-5014674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix avoids a migration failure in the product feed setup when a website would create too many products for a single feed. It now skips the affected websites instead of raising an error, allowing the database upgrade to complete successfully.
Original PR description
``` File /home/odoo/src/odoo/saas-18.4/addons/website_sale_product_feed/models/product_feed.py, line 105, in _check_product_limit raise ValidationError(feed.env._( odoo.exceptions.ValidationError: A…
```
File /home/odoo/src/odoo/saas-18.4/addons/website_sale_product_feed/models/product_feed.py, line 105, in _check_product_limit
raise ValidationError(feed.env._(
odoo.exceptions.ValidationError: A single feed cannot contain more than 5,000 products. Please separate products with Categories.
```
```
(Pdb) feed.env['product.product'].search_count(feed._get_feed_product_domain())
12433
```
During migration I am getting the traceback mentioned above, which is occurring because [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/__init__.py#L14) we have populated feed records in _post_init_hook which will create feed records without any [category ID](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/website.py#L21) because of which, [here](https://github.com/odoo/odoo/blob/saas-18.3/addons/website_sale_product_feed/models/product_feed.py#L101) we get all records without a category, which is of course higher than our soft limit of 5000, and a validation error occurs: the customer database does not have GMC enabled. Still, it calls _populate_product_feeds, which is why I have moved it to a condition.
opw-5180407
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#233365This update fixes a small issue in the Belgium POS black box module when receiving orders from Urban Piper. It helps ensure these orders are handled correctly and reduces the chance of order-processing problems at the point of sale.
Original PR description
Fix small issue in `pos_blackbox_be` module when accepting orders from Urban Piper. Forward-Port-Of: odoo/enterprise#98563
When a product attribute in Point of Sale includes an extra free-text value, that text now appears on the preparation display along with the selected option. This keeps the kitchen or prep view consistent with the receipt and avoids missing order details.
Original PR description
Steps to reproduce: ------------------- 1. Create a PoS product with an attribute of type "Radio", name it "X", and add a value to it, name it "Y", with the "Free text" option selected. 2. From PoS, click the product, for the attribute "X", select the value "Y", and enter some text in the text input area "blabla". 3. Order the product. Observation: On the preparation display, only the attribute name and value are display, but not the entered text, i.e. "X: Y" instead of "X: Y: blabla". Fix: ---- We now show the custom value (free text) if any. This matches what's been shown on the receipt in PoS. opw-5111768 Forward-Port-Of: odoo/enterprise#95874
This update brings the spreadsheet component up to its latest version and includes a fix for how editable text is read and saved. It helps keep spreadsheet editing more reliable and consistent for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/1ba569f40 [REL] 18.4.16 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/828ee0bb3 [FIX] composer: fix get/setText of the content editable helper [Task: 5082601](https://www.odoo.com/odoo/2328/tasks/5082601) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This change corrects a test setup issue in the HTML builder so it uses the proper base option component. It helps keep the automated tests aligned with the current implementation, reducing the risk of false failures and ensuring more reliable validation of future changes.
Original PR description
In PR https://github.com/odoo/odoo/pull/220746, we forgot to replace the use of Component with BaseOptionComponent in few tests. This commit fixes that. 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
The company switcher now correctly displays nested companies a user can access, even when an intermediate company is not available to them. This prevents companies from disappearing from the list and makes it easier to switch to the right company in multi-company setups.
Original PR description
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2…
### Issue: Given a specific configuration, the `SwitchCompanyMenu` will not display all the companies a user can access. Suppose we have a company hierarchy with the following: `Company 1 > Company 2 > Company 3` (where 2 is a branch of 1, and 3 is a branch of 2). If a user has access to C1 and C3, but not C2, the menu selector will only display C1, rather than a hierarchy of all 3 companies with C2 disabled. This menu has been improved between versions, but the logic behind how we determine which companies to display remains consistent. We loop over each root company from `companyService.allowedCompaniesWithAncestors`, add it, and then add its children. Depending on whether the child company is accessible, it will be disabled (but still displayed) in the hierarchy list. `companyService` pulls its company information from the `session['user_companies']` dict that is created from `session_info`. For each of the `allowed_companies`, we build the `child_ids` from the intersection of each `user.company_id.child_ids` and `user.company_ids`. So we only add the child if it itself is an allowed company, which C2 would not be. C1 is now considered a root company with no children in our loop, so C2 is skipped. C2 isn't a root company either, so it will never be seen, and therefore neither will C3. ### Solution: A similar case was addressed in #138942, where given the same company hierarchy as above, the user instead has access to C2 and C3, but not C1. This PR adjusted how we build the `child_ids` for `disallowed_ancestor_companies` (C1 in this case), properly setting the children for us to loop through. We can use this same logic for the `child_ids` of `allowed_companies`, ensuring we can properly loop through the disallowed children of allowed companies. Additionally, we need to adapt the `CompanySelector` component, which previously grabbed all children even if they were disallowed. opw-4880477 Forward-Port-Of: odoo/odoo#229829 Forward-Port-Of: odoo/odoo#217001
This update fixes an error that could appear when editing the countdown snippet’s box layout background color. It ensures the preview keeps working normally even when no extra color is selected, preventing a disruptive traceback for users.
Original PR description
Steps to Reproduce: 1. Add a Countdown snippet. 2. Change the layout to Boxes. 3. Apply a background color to the layout. 4. Hover over the delete button in the color picker. 5. A traceback error occurs. Issue: A traceback error occurs because the does not have a default value assigned. This is necessary for the snippet to preview correctly when no additional color is applied. Fix: Assign a default value to ensure that the hover behavior works properly, even when no color is set. The issue was produced here: https://github.com/odoo/odoo/commit/03c552690b15#diff-a0262b81bb090b8c62afbd342b2a30f054cf353a35f9fc0ceeb0f86b7b9cd645 task-4752497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232094 Forward-Port-Of: odoo/odoo#224012
On very small screens, the empty-state image in the barcode app could cover the scan button and nearby text, preventing users from tapping it. This update adjusts the layout so the button stays accessible, helping warehouse staff continue scanning items on compact devices.
Original PR description
On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items. ### Steps to reproduce: On a small screen size (Zebra…
On small screens (e.g., Zebra scanner, iPhone 4), the image overlaps the barcode scan button, making it impossible to click and scan new items. ### Steps to reproduce: On a small screen size (Zebra scanner, Iphone 4,..) * Open barcode app * Go on Operations -> Receipts * Apply a filter so that the list becomes empty. -> the image is over the barcode button and the text. ### Observation: Our image (in div .o_view_nocontent) has position absolute, anchoring it to the top part of the screen where the search bar is located (in div .o_control_panel). The issue is that in barcode there is another element where the button to scan is located (o_kanban_tip_filter), and since the image is absolutely positioned relative to the top rather than this element, it ends up overlapping the button and the text, preventing interaction. ### Why the fix: The solution we chose is to change the position of the image to relative, for the image to not hide the text. Another possible solution was to make the image (more specifically .o_view_nocontent .o_nocontent_help) ignore all input, allowing them to go through the image and reach the button below. opw-5123880 Forward-Port-Of: odoo/enterprise#98243
When users change the rounding unit in the Journal Report, the Global Tax Summary now updates too. This keeps the tax summary consistent with the rest of the report and avoids confusion from mixed number formats.
Original PR description
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This…
Currently when users change the rounding unit filter in the Journal Report, the Global Tax Summary values remain in the old format instead of updating to reflect the new rounding setting. This creates inconsistency where main report values update correctly but tax summary values stay unchanged. Cause: - The issue occurs because `_format_column_values` method in `account_report.py` wasn't handling the special tax summary data structures (`tax_report_lines` and `tax_grid_summary_lines`) that store pre-formatted values. These structures need to be reformatted when rounding unit changes, but the formatting logic only covered standard report columns. Fix Applied: - Updated frontend (`filters.js`) to call `format_column_values_from_client` via `dispatch_report_action` instead of calling `format_column_values` directly. (this enables proper routing through the custom handler system) - Added `format_column_values_from_client` override in `JournalReportCustomHandler` that intercepts the formatting call and applies special handling for tax summary lines by adding logic to reformat `tax_report_lines` and `tax_grid_summary_lines` monetary fields using their `_no_format` counterparts. - The custom handler then delegates to the base method via `report.format_column_values_from_client()` to format standard columns. - Also added missing `_no_format` fields in `account_journal_report.py` for `base_amount` and `tax_amount` to enable proper reformatting. Forward-Port-Of: odoo/enterprise#98641 Forward-Port-Of: odoo/enterprise#94660
This change removes an Enterprise-only prompt from the Gelato settings screen. As a result, community edition users can install and configure the Gelato module directly from settings without being asked to upgrade first.
Original PR description
Remove the 'Enterprise' widget from Gelato setting, which prevented community users from installing Gelato module from settings without upgrading to enterprise. Forward-Port-Of: odoo/odoo#230776
The label for the address line used in Saudi e-invoicing has been changed from “Street 2…” to “District…”. This helps users enter the correct address information and reduces the risk of misunderstandings or non-compliant invoices.
Original PR description
## Before this commit The `street2` field on `res.company` and `res.partner` was mapped to `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cbc:CitySubdivisionName`, but its placeholder displayed `Street 2…`. This caused confusion among users, as they assumed it referred to `cbc:AdditionalStreetName`, leading to incorrect data entry and potential non-compliance. ## After this commit The placeholder of the `street2` field has been changed from `Street 2…` to `District…`, clarifying that this field represents the city subdivision (district or borough) of the Seller/Customer, in line with the Saudi Arabia e-invoicing specification. > Task-4951545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231923 Forward-Port-Of: odoo/odoo#231160
Website menus linked to pages will now only appear active when the current URL matches exactly. This prevents similar page titles from being highlighted at the same time, making navigation clearer for visitors.
Original PR description
__Current behavior before commit:__ A menu is shown as active if the unslug version of its URL matches the current accessed URL. The issue is that the unslug version of a menu linked to a page has no real meaning. Such menu should only be shown as active if the request URL path matches exactly. __Description of the fix:__ Added a check to ensure that when a menu is linked to a page, it isn't shown as active if its path doesn't exactly match the request path. __Steps to reproduce:__ 1. On the website, go to Site > Pages 2. Create a new page with title "iOS 26" and another page with title "iPadOS 26" 3. Go to /ios-26 4. Both menus "iOS 26" and "iPadOS 26" are highlighted task-5094899 Forward-Port-Of: odoo/odoo#233865 Forward-Port-Of: odoo/odoo#230623
This fix restores website form radio buttons and checkboxes so they send the option’s display name instead of an internal ID. As a result, emails generated from these forms are easier to understand and more useful for end users.
Original PR description
Radio options and checkboxes for the website form were changed such that the values that were linked to their html elements were set as their ID's instead of their display names. This caused issues with sending an email from the form as these ID's are nonsensical to the end user. This change reverts the functionality to instead set the value to the display name in order to give meaningful values back on the email. issue introduced in: https://github.com/odoo/odoo/commit/f4230d74c2209d7902df60d9fed91d8000aa267b value was set to the record idField instead of the record displayNameField causing this issue related change: https://github.com/odoo/odoo/pull/214182 opw-4994387
Product catalog prices now correctly show discounts even when a product has already been added to the order. This fixes a mismatch between the catalog and the order line price display, helping users see the right price at a glance.
Original PR description
Catalog prices do not consider discounts when displayed separately from the unit price on the order line (if any for a given product). It was fixed for the /update_order_line_info route with 5d1837e47c20f04458472658c4f8ea71284fb6ca, but the issue still remained when fetching the original catalog data on opening, through the /order_lines_info route. This only happened when the product was already added to the order, because in this case we avoid recomputing the pricelist price and use the existing sale order line price. This commit makes sure that the sale order line discount field is correctly considered in that case, and also adds tests to cover the catalog more extensively. Fixes #232219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233098
The spreadsheet pivot view now supports grouping by reference-type fields, which lets users count and analyze linked records that point to different models. This is useful for activity reporting and similar business analyses where data is organized by a linked record identifier.
Original PR description
This is a feedback from a partner at OXP, he wants to know the number of activities (late or not) linked to some Lead -> activities grouped by res_id. But grouping a pivot by a many2one_reference is currently not supported. This commit adds the support. Note that carelessly grouping by a many2one_reference mixes records linked to different models (same id, but different model). To avoid mixin apples and oranges, you have to either groupby model, *then* by res_id, or add the model to the domain. Task: 5102923 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232115 Forward-Port-Of: odoo/odoo#227939
6 changes
Resolved issues and error corrections
Website menus linked to pages will now appear active only when the visitor is on the exact matching page path. This avoids unrelated pages being highlighted at the same time, making navigation clearer and less confusing for users.
Original PR description
__Current behavior before commit:__ A menu is shown as active if the unslug version of its URL matches the current accessed URL. The issue is that the unslug version of a menu linked to a page has no real meaning. Such menu should only be shown as active if the request URL path matches exactly. __Description of the fix:__ Added a check to ensure that when a menu is linked to a page, it isn't shown as active if its path doesn't exactly match the request path. __Steps to reproduce:__ 1. On the website, go to Site > Pages 2. Create a new page with title "iOS 26" and another page with title "iPadOS 26" 3. Go to /ios-26 4. Both menus "iOS 26" and "iPadOS 26" are highlighted task-5094899 Forward-Port-Of: odoo/odoo#233865 Forward-Port-Of: odoo/odoo#230623
Scanning a barcode in the product search now reliably uses the entire barcode instead of sometimes stopping at a partial value. This prevents incorrect searches and helps users find the right product faster and more consistently.
Original PR description
Issue ----- When scanning a barcode in the product view, the search is made using only part of the barcode. Steps to reproduce ----- - Open the product view - Scan a barcode (eg 1234567890) > The search might only contain 12345678, 123456 or actually the full barcode Cause ----- When scanning a barcode, we receive all of the barcode characters followed by newline. When we receive the newline, we select the first item in the dropdown. The problem is that the search input changed but it hasn't been reflected yet in the items (a rendering is scheduled but hasn't been applied to the DOM yet). ----- Ticket: opw-4874425 Forward-Port-Of: odoo/odoo#232270
This change improves how ribbons and status bars look in pop-up forms. It keeps the ribbon visually separate when a status bar is present and preserves a clean layout while scrolling, making the form easier to read and less cluttered.
Original PR description
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See…
Previously, `position: static` was added on `.o_form_sheet` in modal forms to fix an issue where the ribbon looked ugly (not pinned to the top right) due to the absence of borders in modals. See commit: https://github.com/odoo/odoo/commit/1ac2ff5b7dd64ccfe1bfb9c3fb7bb8a758e887d7 However, when a statusbar is present, this rule caused the ribbon to merge into the statusbar, making its display worse. In addition, on scrolling in a modal, the statusbar and the form contents were getting merged. This commit refines : - the selector so that `position: static` is only applied when a modal form has a ribbon but no statusbar. When a statusbar exists, the ribbon remains visually separated from the statusbar. - the statusbar background-color logic so that inside modals it uses the proper `$o-view-background-color`, ensuring a clean separation even on scrolling. task-4873636 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226074
Guests who have not been active in the last 12 hours will no longer receive notifications when a call starts. This reduces unnecessary alerts and helps avoid contacting people who are likely no longer available.
Original PR description
With this commit, guests who haven't been online in the last 12 hours will not be notified of a call starting. task-5136330 backport of https://github.com/odoo/odoo/pull/230337 Forward-Port-Of: odoo/odoo#233669 Forward-Port-Of: odoo/odoo#233221
This update corrects how device certificates are read on older IoT boxes, ensuring the system uses the right method for each version. It prevents compatibility issues and avoids warning messages without changing the expected behavior for users.
Original PR description
To avoid a deprecation warning on `x509.Certificate`, we switched from `not_valid_after` to `not_valid_after_utc`, and patched the newer version to point to the previous one if the iot box was before a certain version. However this patch wasn't working properly as the certificate object isn't patchable (not python type). We now call the specific method depending on the version everytime we need this attribute.
This fix ensures the currency and unit shown for emitted emissions refresh properly when the emission factor changes. It prevents outdated values from being displayed in ESG reports, improving accuracy and consistency for users.
Original PR description
The `currency` and `unit` fields on emitted emissions are supposed to be related fields on the emission factor. However, due to how the report combining accounting emissions and other emissions is implemented, they are not correctly updated when the factor is modified. This PR makes them computed fields and enable the "store" attribute en them. Despite there being no actual table to store data into, this allows us to do a round trip to the server to fetch the correct values.
12 changes
Resolved issues and error corrections
This update removes customers linked to non-trade receivable accounts from the Point of Sale customer list, so cashiers only see suitable customers when selecting one at checkout. It also adds two new VAT accounts to the Belgian chart of accounts for the Collection Center partner, improving local accounting setup.
Original PR description
This PR removes the partners with non-trade receivable accounts from the POS customer's list. Additionally, 2 new VAT accounts were added in BE COA to be added on "Collection Center" partner. task-5148985 Current behavior before PR: - Partners with non-trade receivable accounts were visible in POS customer list Desired behavior after PR is merged: - Partners with non-trade receivable accounts were not visible in POS customer list - 2 new accounts added to BE CoA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix brings back the tax detail breakdown in the journal audit report, including the + and - columns that were removed by mistake. It helps users review tax grids accurately and keeps the report consistent with expected accounting details.
Original PR description
During the removal of tax tag signs, the detail of the tax grids has been removed and both columns `+` and `-` have been removed by mistake.
This update brings the spreadsheet component up to its latest version, including a fix for text handling in editable content areas. It helps keep spreadsheet editing more reliable and aligned with the newest upstream improvements.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/10359f499 [REL] 19.0.9 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ab1bc9362 [FIX] composer: fix get/setText of the content editable helper [Task: 5082601](https://www.odoo.com/odoo/2328/tasks/5082601) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This update makes Belgian VAT-related partner accounts use the correct receivable and payable accounts, so VAT payments and closing entries are recorded more reliably. It also adds a new reconciliation rule that matches the partner and payment reference to automatically create the offsetting entry, reducing manual work and improving bank matching.
Original PR description
This commit sets AR and AP accounts of "FPS" and "Collection Center" partners with the 2 new added VAT accounts. Additionally, a new reconciliation rules that detects the partner and the communication and creates a counter entry. The partner "FPS" have been added to the VAT closing line for auto-reconciliation with bank transaction. task-5148985
The payroll CFDI PDF was showing some employee information in the employer section. This fix places the details in the correct area so the document is clearer and avoids confusion when sharing payroll records.
Original PR description
Some info related to the employee is shown in the employer section. Task: 5224191
This fix makes ZATCA invoice checks run even when a company does not have a country set. It helps prevent invalid invoices from causing errors that could stop the EDI service from processing documents reliably.
Original PR description
ZATCA invoice misconfigurations are only checked for if the company has Saudi Arabia set as its country. However, ZATCA EDIs can be generated without Saudi Arabia set as the country. Thus, companies without a company set can create EDI documents for misconfigured invoices. This may cause traceback errors which prevent the "EDI : Perform web services operations" cron from running at all. This commit ensures that configuration checks are run on companies without countries set (and adds a relevant unit test). opw-5057792 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233333 Forward-Port-Of: odoo/odoo#231255
This change prevents a crash that could happen when Odoo recalculates task dependency warnings. It ensures the warning is checked safely for each task, so updating a deadline no longer breaks dependent tasks when several are linked to the same blocker.
Original PR description
Currently, an error occurs when computing the dependency warning for tasks. **Error:** ```Expected singleton: project.task(8, 7).``` After [this commit] if task1 depends on task2, if task1's task…
Currently, an error occurs when computing the dependency warning for tasks.
**Error:**
```Expected singleton: project.task(8, 7).```
After [this commit] if task1 depends on task2, if task1's task dependency is False, then the dependency warning for task1 should also be False.
However, when task dependency is enabled and two or more tasks are blocked by a single task, changing the Deadline of the blocking task triggers the computation of the dependency warning for those dependent tasks. During this process, the system attempts to check the task dependency across multiple records, which raises the error at [1].
This commit ensures that, since self may contain multiple tasks, the dependency warning is computed safely for each specific task.
[this commit]: https://github.com/odoo/enterprise/commit/50768627accb9d9767514fda7c6975bf4d8227d3#diff-b4bb763881453b0d69cae371c4c5034f6e199dfaf3a3056aba3381cf64dbf3dc
[1]- https://github.com/odoo/enterprise/blob/769201e22618b6683863f0839d7ad80bea0927cf/project_enterprise/models/project_task.py#L350
sentry-6914184933The remaining days field now uses the updated date formatting when showing a date. This makes the displayed date consistent with the rest of the app and improves readability for users.
Original PR description
Before this commit, remaining_days widget was not using the new date formatter when showing the date. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Website menus linked to pages will now only appear active when the visitor is on the exact matching page. This prevents the wrong menus from being highlighted at the same time, making navigation clearer and more accurate for visitors.
Original PR description
__Current behavior before commit:__ A menu is shown as active if the unslug version of its URL matches the current accessed URL. The issue is that the unslug version of a menu linked to a page has no real meaning. Such menu should only be shown as active if the request URL path matches exactly. __Description of the fix:__ Added a check to ensure that when a menu is linked to a page, it isn't shown as active if its path doesn't exactly match the request path. __Steps to reproduce:__ 1. On the website, go to Site > Pages 2. Create a new page with title "iOS 26" and another page with title "iPadOS 26" 3. Go to /ios-26 4. Both menus "iOS 26" and "iPadOS 26" are highlighted task-5094899 Forward-Port-Of: odoo/odoo#233865 Forward-Port-Of: odoo/odoo#230623
This change removes an Enterprise-only setting from the Gelato integration, so Community users can install and configure it directly from the settings screen. It prevents an unnecessary upgrade prompt and makes the setup experience smoother for more customers.
Original PR description
Remove the 'Enterprise' widget from Gelato setting, which prevented community users from installing Gelato module from settings without upgrading to enterprise. Forward-Port-Of: odoo/odoo#230776
This change updates how company logos are fetched for partner autocomplete, moving the lookup from the browser to Odoo’s enrichment service. It replaces the previous provider with a new one and ensures logos are retrieved more reliably when enriching company data, rather than during search selection.
Original PR description
Before this commit- We used to rely on clearbit to fetch the logo of the company on the client side After this commit- We replace it with logo.dev and remove the fetching of logo from client side and move it to the IAP task-5126337 IAP PR- https://github.com/odoo/iap-apps/pull/1234 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234053 Forward-Port-Of: odoo/odoo#231397
The payment screen no longer shows the total amount on payment method buttons when cash rounding is not configured. This reduces confusion for cashless or standard sales and makes the checkout display more accurate.
Original PR description
Before this commit: ==================== The total amount was displayed on payment method buttons on the payment screen even when no cash rounding method was configured. After this commit: ======================= The total amount is no longer shown on payment method buttons if no cash rounding method is configured. Task-5219865
5 changes
Resolved issues and error corrections
This change ensures that default values in mocked fields are kept when test models are extended. As a result, date-related fields like creation and last update timestamps are filled in correctly during tests, making them more reliable.
Original PR description
Before this commit, default values in mock fields defined by functions would be lost when extending a model, because by doing so the fields were JSON-copied and the default functions were lost. To fix this, this commit introduces another way to copy field definitions that preserves functions, allowing default values (typically for the 'create_date' and 'write_date' fields) to be applied correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix improves how Swedish bank account numbers are identified when exporting partner bank details. It now correctly recognizes several valid account formats that were previously treated as invalid, reducing errors in exported data and helping ensure payments are handled correctly.
Original PR description
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the…
### Issue: Some valid Swedish account numbers are not recognized as Swedish. ### Steps to reproduce: - Install 'l10n_se_bban' and switch to Swedish company - Create a new partner, under the 'Accounting' page create a new bank account 1- 62074-0 2- 678653833066 3- 99603406872188 - In the partner list view select this new partner - Click Actions > Export, select "Banks" and "Bank Type" - Check the file 1- 62074-0 not recognized as Plusgiro 2- 678653833066 not recognized as BBAN 3- 99603406872188 not recognized as BBAN ### Cause: These numbers are not recognized by the checks of Odoo but are valid numbers: 1. Plusgiro account numbers can be 2 to 8 digits long, Odoo accepted only 7 to 8 digits account numbers 2. Old Handelsbanken numbers (6000-6999) can have 8 digits instead of 9, Odoo only accepts 9 digits numbers 3. Only clearing numbers starting with 8 are 5 digits long, Odoo also included ranges 9500-9549 and 9960-9969 ### Sources: 1 and 3: https://www.amcbanking.com/kb/swedish-payments-how-to-configure-sender-and-vendor-bank-accounts-in-fo/ 1 and 3: https://github.com/Tobbe/kontonummer.js/blob/04959502d7d2d52938aabda80b8a3464efddfdd1/kontonummer.js 2: https://github.com/barsoom/banktools-se/commit/b964806d5cad0491ea121419520fd5b5d4478c15 opw-5099867
This change fixes an access problem that prevented some Recruitment administrators from sending referral campaigns. Users with the right recruitment permissions can now complete the action without needing extra employee access rights.
Original PR description
STEP TO REPRODUCE:
------------------
1- Give to Marc Demo the right : Recruitment / Administrator (be sure he doesn't have any right on Employees)
2- Log as Marc Demo
3- Go to Recruitment
4- Click on the three dots in kanban card
5- Click on Referral Campaign
6- Click on Send
You will have an access error
This user (with these groups) should be able to send a referral campaign
task-5082344This change updates a sales/manufacturing test so it no longer relies on a field that is only available in the Enterprise edition. It helps the test run correctly in more setups and prevents avoidable test failures.
Original PR description
Cause ----- Test introduced in 2da1c78 uses the field `backorder_ids` which is only present when enterprise is installed https://github.com/odoo/enterprise/blob/67fdbc5ae724a184d62d8cfa23403b8c759b9317/stock_barcode_mrp/models/mrp_production.py#L10 ----- Error: 233584
This update fixes a problem where some appointment pages could fail to load with a 404 error when the assigned staff member has flexible working hours. It ensures availability is checked correctly so customers can view the appointment details without interruption.
Original PR description
This PR fixes the 404 error displayed on the info page of a "Limit to Work Hours" appointment linked to a staff user with flexible hours. The availability of the staff user must not be computed from its work schedules as it has flexible hours. Task-5046134
2 changes
Resolved issues and error corrections
This change corrects how overtime one-time payments are processed in Swiss payroll transmissions. It helps ensure these payments are sent with the right information, reducing payroll errors and manual corrections.
This change prevents stopped call ringtones from being restarted accidentally using media keys after the call has ended. It helps avoid unexpected audio playback and makes call handling behave more predictably for users.
Original PR description
Before this commit, users can resume "stopped" ringtones by pressing the Media Play/Pause key of their keyboard/headphones, even after the call has ended. After this commit, stopping the ringtone clears the audio source, effectively preventing it from being resumed. Task-5222704 opw-5186087