Daily updates from Odoo
Tuesday, May 27, 2025
49 changes · 18.0
New functionality added to Odoo
Companies can now use the Bank of Slovenia as a source for live currency exchange rates. This gives businesses operating with Slovenian or related currencies another official provider option and keeps rates updated through the bank's API.
Original PR description
In this PR: - Added Bank of Slovenia to the list of currency providers. - Fetches exchange rates using the official API and updates the rates. Task-4794271
Enhancements to existing features
Public holiday imports are now processed in batches, which greatly reduces the time needed when holidays overlap with existing time off or planning entries. This helps HR teams import large holiday calendars much faster, improving from minutes to seconds in the example provided.
Original PR description
Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this…
Importing new public holidays from an xlsx file can take quite some time at the moment because Odoo has to reclaim past time off if it overlaps with one of the new public holidays. Currently this whole process is not properly batched. There is a single record creation in `hr_holidays:_reevaluate_leaves` and a single record write in `planning:_compute_allocated_hours`. This commit optimizes the Public Holidays creation by batching the two methods mentioned above. Batching the create call is straightforward. Batching the write might seem useless at first as UPDATE queries are already batched on the ORM level. But actually the performance bottleneck comes from the post-processing done after writing a new `planning_slot.allocated_hours` value. By grouping the slots by allocated_hours we can speed up this post-processing. #### speedup Trying to import 72 new Public Holidays that lead to writing allocated hours on 85 planning slots - 2min -> 4.76s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now avoids reloading pricelist details that were already fetched earlier. This reduces unnecessary data transfer and helps sessions load faster, especially for businesses with large pricelists.
Original PR description
Before this commit, loading missing pricelist items would also resend the entire pricelist record, even though pricelist records are already loaded at the beginning. This caused unnecessary data transfer and slower performance, especially when pricelists contained many items. opw-4812031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Invoice and accounting forms now place the cursor in the customer field, or the reference field when customer is unavailable, instead of the document number. This helps prevent accidental edits to accounting sequences and improves form usability when users start typing immediately.
Original PR description
*: account, partner_autocomplete, web --- This PR is a backport of [this PR](https://github.com/odoo/odoo/pull/203522) Some changes have been made to it for retro compatibility while allowing the change in stable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users create a new account move, the cursor now starts in the next editable field instead of the displayed name field. This helps prevent accidental changes to document numbering or sequence information during data entry.
Original PR description
made the default focus to be the next editable field in the form view when people create a new account move the cursor focus on the desplayed name so people tend to mess up the sequence so we changed the focus to the next editable field to not mess up the sequence task-4558713 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
Public holiday planning entries are now created more efficiently by grouping similar schedule updates together. This reduces processing time when many planning slots are updated, improving responsiveness for teams managing calendars and holidays.
Original PR description
Related to odoo/odoo#209846
Resolved issues and error corrections
Odoo now keeps bus messages for longer before cleanup, reducing the chance that users miss updates after a temporary disconnection. Administrators can also adjust the retention period to fit their operational needs, with a safer default of 24 hours.
Original PR description
Before this commit, the bus GC would remove every message older than 120 seconds. This could lead to missed messages if a disconnection occurred during the GC process. To minimize the impact of GC, the retention window should be extended. This commit introduces the `bus.gc_retention_seconds` config parameter, which allows customizing this window. The default is set to 24 hours, which seems reasonable (messages won't be cleared overnight). Since the GC will now process larger batches, the deletion is not made with a direct query: no need to fetch all records before calling `unlink`, no need to schedule other vacuums when the batch is too big.
Point of Sale now clears outdated quotation data after a down payment so it can reload the latest order details before settlement. This prevents incorrect settlement results, such as product quantities being reset, and helps ensure quotations paid through POS remain accurate.
Original PR description
## Issue: Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling. ## Reason: During the down payment…
## Issue: Completing a flow from quotation to payment (down payment → settle) via Point of Sale does not properly update the sale order lines when settling. ## Reason: During the down payment process, the PoS adds new lines to the sale order. These are added during the order validation stage. However, the updated order lines are not written back to IndexedDB. If the user attempts to settle the order without reloading the session or clearing the cache, the PoS relies on stale data from IndexedDB. This causes Odoo to see outdated `order_lines`, usually only the original item(s), leading to incorrect behavior such as product quantities resetting to 0. ## Fix: To ensure data consistency, we explicitly remove the affected sale orders from IndexedDB after the down payment is completed. This forces the PoS to re-fetch the updated order from the backend. The re-fetch happens through the `missingRecursive` function, which will retrieve the complete and up-to-date sale order data, including the new order lines, ensuring accurate behavior during the settlement process. ## Steps to reproduce: 1. Create a service product with "Ordered quantities" as the invoicing policy. 2. Create a quotation using this product. 3. Open the PoS. 4. Click "Actions" → "Quotations" → select the quotation. 5. Choose the "Down Payment" option (any type) and set amount/percentage. 6. Pay the order. 7. Again, go to "Actions" → "Quotations" and select the same order. 8. Click "Settle the order". 9. At this point, Odoo will incorrectly reset product quantity to 0. OPW-4811612 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales order lines for products with non-variant or custom attributes now keep the product name as the main display name instead of showing the attribute name. This also ensures related tasks created from confirmed orders use the correct product-based name, reducing confusion for sales and project teams.
Original PR description
This reverts commit 2094747717be Versions -------- - 18.0+ Steps ----- 1. Create a service product that creates a task on order confirmation; 2. add an attribute that does not create variants; 3. add…
This reverts commit 2094747717be Versions -------- - 18.0+ Steps ----- 1. Create a service product that creates a task on order confirmation; 2. add an attribute that does not create variants; 3. add the product to an order; 4. confirm the order. Issue ----- 1. The task is named as the attribute. 2. The line's `display_name` shows the attribute instead of the product. Cause ----- Commit 2094747717be removed the extra new line that was added before attribute-based line descriptions for custom attributes and attributes that create no variants. This did not impact the task or display name in previous versions, as the default sale order description started with the product name, and could be replaced. But as of 18.0, while the default sale order description still starts with the product name, it's no longer possible to replace it, hence it gets skipped to get the first line of the editable description, which in this case is the attribute name. Solution -------- By re-adding the empty line before the attribute descriptions, the display & task names will fall back on the product name. See commit 47d223759f07 for display name & c3877b2acd74 for task names. Also adds a test to prevent regression. opw-4792351
Point of Sale session reports now correctly show counted amounts when bank payments include refunds or other negative transactions. This prevents mismatched payment totals and gives businesses more reliable end-of-session reporting.
Original PR description
Before this commit, if a session included negative bank payments resulting in a negative total, the session report displayed incorrect counted amounts and mismatched values for the bank payment method. opw-4714251 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents pivot report exports from crashing when a numeric field is used in the row grouping. Business users can now download CSV or Excel exports from affected reports reliably, including reports such as Sales Analysis.
Original PR description
Steps to reproduce: - Go to any Report (Ex: Sale Analysis) - Switch to the pivot view - Add on y-column any **int** field - Download as csv Tracebrack is thrown, because the controller tries to concat int to str in the csv generated file. opw-4762807 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
Invoice PDFs now handle unusually long tax group names without pushing the total amount off the page. This keeps invoice totals readable and avoids layout problems when printing or sharing invoices.
Original PR description
**Issue** When the tax group name is too long, it pushes the total amount off the page in the invoice PDF, making the amount unreadable. **Steps to Reproduce** 1. Install the Accounting module. 2. Go to Taxes. 3. Select a tax and open Advanced Options. 4. Set a very long name for the tax group. 5. Go to Accounting > Customers > Invoices. 6. Create and confirm an invoice using the tax with the long group name. 7. Print the invoice PDF and observe the layout issue. **Root Cause** The text-nowrap CSS class prevents the tax group name from wrapping, causing it to expand the table cell width and push the amount outside the page boundary. **Fix** Remove the text-nowrap class and apply a maximum width to the <td> element, allowing the tax group name to wrap or truncate properly without overlapping or pushing the total amount off the page. Opw-4795941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Tax closing accounts are now kept separate from tax line and default payable or receivable accounts, preventing incorrect tax closing amounts. The update also makes these tax authority accounts reconcilable, helping businesses match bank payments or refunds more easily.
Original PR description
In some localizations, the same accounts were used on tax groups (for tax closings), on tax repartition lines, and/or as default payable or receivable account. Having the same account on two of these types causes issues with the tax closing amounts being incorrect. This commit makes sure all accounts are distinct for the different types and creates new ones if necessary. It also adapts the tax closing accounts in all localizations to be reconcilable accounts, either payable or receivable, but non-trade. That way users can easily reconcile bank transactions with the tax authorities. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/enterprise/pull/85693
The accounting system now consistently runs the expected follow-up actions when an invoice becomes paid or enters payment processing. This helps prevent missed business workflows that depend on invoices being recognized as paid, such as updates, notifications, or related automations.
Original PR description
Before: - _invoice_paid_hook() was only triggered during reconciliation. After: - _invoice_paid_hook() is now reliably triggered in _compute_payment_state() when an invoice transitions to "paid" or "in_payment". task-4277444
Calendar popovers now display each task property with its own label instead of reusing the general container label. This makes custom property information clearer and consistent with how standard fields are shown.
Original PR description
Backport of 18affd81cbdd321e428b729602f91dc06988929f Steps: ------ * Add properties (displayed on card) to a task of a project * Open the card view of the task in the calendar view of the project Previously, the calendar popover displayed property field values using the label of the container field. This commit updates the behavior to display each property field with its respective label, ensuring consistency with the appearance of standard fields. opw-4767059 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes cases where purchase and sales replenishment flows could assign the wrong customer to internal warehouse transfers when different fulfillment routes were mixed. Businesses using cross-dock, make-to-order, and stock-based purchasing together will get more accurate picking documents and fewer delivery-processing mistakes.
Original PR description
When mixing cross-dock (XD), MTO and MTS products, it may lead to incorrect partners on the pickings. To reproduce the issue: 1. Enable Multi-Routes 2. Edit the warehouse: 2-steps reception, 2-steps…
When mixing cross-dock (XD), MTO and MTS products, it may lead to
incorrect partners on the pickings.
To reproduce the issue:
1. Enable Multi-Routes
2. Edit the warehouse: 2-steps reception, 2-steps delivery
3. Unarchive MTO route
4. Setup 3 products:
- Storable
- Routes:
- All with buy
- One MTO
- One XD
- Same supplier
5. Create and confirm one SO for each product (starting with XD one),
each one with a different customer
6. Validate the generated replenish
7. Confirm the PO
8. Process the receipts
Error: The internal pickings have the same defined partner, the
customer of the XD product.
There are two issues:
- The destination address of a purchase is defined on the PO level,
not the POL one
- When looking for a PO, the `_run_buy` mechanism doesn't filter on
the destination address
This explains why:
- All purchases are gathered on the same PO
- On the internal pickings, we will find the first destination address
Even though the first point is convenient, since the destination
address is defined on the PO level, it leads to incorrect results.
However, changing this on stable is too risky. The only (and sad)
thing we can do so far is the creation of an ICP that would split
all PO based on their destination address. On master, this address
will be defined on POL level.
OPW-4552316Fixes an issue in the homeworking calendar where changing the time format could trigger an error when moving between calendar views in debug mode. This makes calendar navigation more reliable for users who adjust time display settings.
Original PR description
**Issue**:
an error is thrown in debug mode when switching between calendar views ("year", "week", etc.) after changing the time format.
**Steps to reproduce:**
- ensure hr_homeworking_calendar is installed
- activate debug mode
- Calendar > change the time format
opw-4684831The Point of Sale mobile screen now keeps the search dropdown visible above the orders list. This fixes an issue that made searching orders difficult or unusable on smaller screens.
Original PR description
The search field dropdown was being rendered behind the orders list in mobile view, making it unusable. This commit adds a higher z-index to the search field dropdown to ensure it's rendered above the orders list. opw-4654710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening a combo product on the website no longer fails when one of its linked combo items was deleted. This avoids a customer-facing error page and keeps the online shop usable even when product data has changed.
Original PR description
If a user tries to open a combo product on the website and the combo item has been deleted, a traceback will appear. Steps to reproduce the error: - Install ``website_sale_stock`` module - Create…
If a user tries to open a combo product on the website and the combo item
has been deleted, a traceback will appear.
Steps to reproduce the error:
- Install ``website_sale_stock`` module
- Create ``Product A`` > product type: ``Goods`` > Save
- Go to Website > eCommerce > Combo choices > Create New(``Combo choice A``) >
Add ``Product A`` in combo item
- Create ``Product Combo A`` > product type: ``combo`` > Combo Choices: ``Combo choice A``
- Delete ``Product A``
- Go to Website > Shop > Open ``Product Combo A``
Traceback:
```
File "/home/odoo/src/odoo/addons/website_sale_stock/models/product_combo.py", line 25, in _get_max_quantity
return max(max_quantities) if (None not in max_quantities) else None
ValueError: max() iterable argument is empty
```
https://github.com/odoo/odoo/blob/4d3b220b0ec6e718f962979b3f271ea161997322/addons/website_sale_stock/models/product_combo.py#L21-L24
Here, when the user deletes the product, ``self.combo_item_ids`` becomes empty,
resulting in ``max_quantities`` being an empty list ([]),
which causes the above traceback.
sentry-6589160704
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers can now add a Pricer Sales Pricelist while creating a product variant before it has been saved. This prevents an error that interrupted product setup and improves the reliability of the product form workflow.
Original PR description
An error occurs when a user attempts to set the **Pricer Sales Pricelist** on a product variant that has not yet been saved. **Steps to reproduce:** - Install the `pos_pricer` module. - Open the form view of **Product Variants**. - Without saving the record, try to add a **Pricer Sales Pricelist**. - Observe the error. **Error:** `KeyError: False` **Cause:** When the product variant is unsaved, `product.id` is `False`, leading to a `KeyError` at [1], because `False` is not a valid key in the result of method `_compute_price_rule()`. [1] - https://github.com/odoo/odoo/blob/d352cfcfe0fe8c161392f3c39ea3e64b7c98bd69/addons/product/models/product_pricelist.py#L140 This commit ensures that users can add a 'Pricer Sales Pricelist' to a product variant, even before saving it. Sentry - 6598605111
Website editors can now delete all text from a button, save the page, and still edit that button later. This prevents buttons such as “Apply Now!” on job pages from becoming inaccessible after content cleanup.
Original PR description
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is…
Problem: When the "Apply Now!" button text is deleted (e.g., on `/jobs/experienced-developer-4`), it becomes uneditable after saving. Cause: When all text is deleted, a zero-width space (ZWS) is inserted with the `data-oe-zws-empty-inline` attribute. This is removed during the save process. Since the button has `data-oe-field="arch"` and becomes empty, it is excluded from editable areas in `_getContentEditableAreas`, making it uneditable after reload. This worked in 17.0 due to inherited `display: block` from a floated parent, which added a `<br>` in empty blocks. Solution: Preserve the ZWS for inline empty elements with `data-oe-field="arch"`, ensuring the element remains editable after save. Steps to reproduce: 1. Navigate to `/jobs/experienced-developer-4`. 2. Open the web editor. 3. Delete the text inside the "Apply Now!" button. 4. Save the page. 5. Reopen the web editor. → The button is no longer editable. opw-4737255 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in the HTML editor where pressing Tab inside a table header cell could cause an error. Users can now navigate tables with header cells more reliably without interrupting their editing work.
Original PR description
Problem: `shiftCursorToTableCell` is not considering being inside `th` which causes traceback as `currentTd` will be null. Solution: Include `th` in the selector alongside `td` to ensure proper detection and navigation. Steps to reproduce: - Copy and paste in the editor any table that has `th`. - Put selection inside a `th` element. - Press "TAB". → Traceback occurs. opw-4808751 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Document tags can now display the custom tooltip text set by users instead of always showing the tag name. This makes tag details clearer when hovering over tags in document views and avoids misleading or incomplete hover text.
Original PR description
Before this commit --- The tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. (The tooltip was not fetched.) After this commit --- We fetch and display the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 A sibling https://github.com/odoo/enterprise/pull/79496 updating xml and utilizing this change
This fix makes list column width handling more reliable, especially for right-to-left layouts and custom integrations that may not pass newer options. It helps prevent display issues or errors in list views while preserving compatibility for existing custom code.
Original PR description
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was…
This commit is a followup of [1]. It does two things: 1) it fixes the "rtl" check that was forwardported from 16.0, where the callback was defined in the renderer and for which `this` was unambiguously the renderer. As of 18.0, the code was moved to an hook, so using `this.isRTL` worked, but kind of by chance. This commit removes the ambiguity and makes the code a bit more robust. 2) using the newly added parameters `options` in `listViewWidths` callbacks looked harmless. Indeed, it causes no issue in standard odoo. However, as reported in [2], there is a world where `options` is undefined. I couldn't really find how, as it works fine even with the suggested culprit [3]. So this commit simply adds a fallback, which makes sense in stable in case there would be custom code calling those `listViewWidths` functions without options. In master though, we expect from people to adapt their code with respect to this change. [1] https://github.com/odoo/odoo/pull/210584 [2] https://github.com/odoo/odoo/issues/211243 [3] https://github.com/OCA/web/tree/18.0/web_remember_tree_column_width closes #211243 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
Changing the unit of measure while processing a receipt in the barcode app now updates the reserved quantity to match. This prevents mismatches between recorded received quantities and demand/reservation figures, improving stock accuracy.
Original PR description
Steps to reproduce:
- Create a storable product “P1”:
- UoM: Unit
- Create a receipt for 200 units of P1
- Mark it as To Do
- Go to the barcode module and start processing the receipt
- Edit the quantity:
- Set it to 2 and change the UoM to Dozen
- Save
Problem
The quantity done is correctly set to 2 dozens, But the reserved quantity remains 200
Solution:
When the UoM is changed, compute and update the reserved quantity accordingly
OPW-4716104Manufacturing barcode screens now show and group by-products by their destination location instead of the source location. This reduces confusion for production operators and allows by-product lines to be edited even when source-location scanning is mandatory.
Original PR description
Issue Before This Commit: ============================ In MO barcode interface, the by-products section displays the source location instead of the destination location for each by-product line. This…
Issue Before This Commit:
============================
In MO barcode interface, the by-products section displays the
source location instead of the destination location for each by-product line.
This is misleading, as by-products are outputs of a production
process and should reference a destination location.
Steps to Reproduce:
============================
- Install the stock_barcode_mrp module.
- Activate multi-step routes and By-Products.
- Create a Manufacturing Order with by-products.
- Open the MO using the barcode app.
- In the by-product section notice that:
- The lines are grouped by Source Location.
- If you edit by-product line then user has option to edit source location.
- If the MO operation type has Source Location scan as mandatory,
user can't edit by-product line.
With This Commit:
============================
- By-product lines are now grouped by their destination location.
- The destination location is displayed for each by-product line.
- The source location field is hidden when editing by-product lines.
- Even if the MO operation type has Source Location scan as mandatory,
users can still edit by-product lines.
This fix improves clarity and usability for production operators by ensuring
that the appropriate location context is accurately displayed and
can be edited when necessary.
task - [4654161](https://www.odoo.com/odoo/my-tasks/4654161)The Documents app now defaults Kanban views to show the most recently updated documents first. This fixes a sorting issue that could make new or unopened documents difficult to locate, helping users find recent files faster.
Original PR description
Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096
The Italian Libro Giornale Journal Audit PDF report now handles long journal item descriptions without disrupting the layout. This ensures debit and credit amounts remain visible in printed reports, improving reliability for audit and accounting documentation.
Original PR description
Before this PR: When generating the Libro Giornale Journal Audit report as PDF, journal items with long descriptions would cause rendering issues. The Name column would expand excessively to accommodate the long text, resulting in the Debit and Credit columns being cropped or completely missing from the printed report as seen in below image.  After this PR: The Libro Giornale Journal Audit report now correctly handles journal items with long descriptions. The report template has been modified to ensure proper column width distribution, preventing the Name column from expanding excessively. The Debit and Credit columns are now consistently displayed in the PDF report regardless of description length.  OPW-4788257
Updates internal test data so tax group receivable and payable accounts follow the latest accounting validation rules. This helps ensure accounting, tax report, localization, and subscription tests continue to reflect compliant account setup without changing customer-facing functionality.
Original PR description
In the related community commit, we added a constraint that requires the Tax Receivable and Tax Payable accounts on tax groups to be a Receivable or Payable account, be reconcilable and set to Non Trade. In this commit we adapt the current tests that use accounts on tax groups to have their accounts comply to the new constraint. [task-3763030](https://www.odoo.com/odoo/project.task/3763030) Related to https://github.com/odoo/odoo/pull/201249
This fix prevents an error in Mexican electronic invoicing for Point of Sale when a cashier selects a company contact on the payment screen. Orders are now only marked for invoicing once the required customer information is complete, reducing checkout interruptions.
Original PR description
Before this commit, selecting a contact of type "company" on the payment screen would result in the following error: `TypeError: Cannot read properties of undefined (reading 'name')` This occurred because selecting a company contact automatically set the order to be invoiced, even if the required fields were not filled in. To prevent this error, the process now checks that all necessary fields are completed before setting the order to invoice. opw-4773831
Document tags now display the custom tooltip text configured for them when users hover over a tag, instead of always showing the tag name. This makes tag guidance clearer for users and ensures the existing Tooltip field works as intended across document-related views.
Original PR description
[FIX] documents: display tag tooltip on hover when possible Before this commit, the tooltip shown on hover over document tags was always the tag name. This ignored the "Tooltip" field available on document tags. After this commit, the system correctly fetches and displays the custom tooltip defined in the "Tooltip" field of the tag. Reproduce --- - install documents - add "Tooltip" string to a TAG in Documents/Configuration/Tags - open documents kanban view and over onto the TAG - BUG: tag name is apearing on hover (instead of tooltip string) opw-4567814 # (older) sibling PR: https://github.com/odoo/odoo/pull/210147
Miscellaneous changes
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super(
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal.…
Versions -------- - 17.0+ Steps ----- 1. Create a new internal user with some administrator rights; 2. set notification preference to "Handle in Odoo"; 3. save changes; 4. switch user type to portal. Issue ----- Validation Error: The user cannot have more than one user types. Cause ----- In the write method of `UsersImplied`, a check happens on whether a user was demoted, by saving the internal users before `super().write`, and comparing it to the internal users after `super().write`[^1]. [^1]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1455-L1457 This was working fine until commit 141852dc6613c introduced the `_inverse_notification_type` method[^4]. It adds or removes the `mail.group_mail_notification_type_inbox` group from users when the `notification_type` gets changed. [^4]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/addons/mail/models/res_users.py#L54-L58 In our first call to `UsersImplied.write`, we store the user as an internal user and call `super().write`. This unlinks `base.group_user`, links `base.group_portal` and sets `notification_type` to `email`. Before returning from `super().write`, the `_inverse_notification_type` method gets triggered to unlink the inbox group, which will lead to a recursive call to `UsersImplied.write`. The recursive call no longer registers the user as internal or being demoted, hence it will re-add `base.group_user` as an implied group[^2] of its still present administrator group, leading to the `api.constrains` violation in `_check_one_user_type`[^3], as we already have the `base.group_portal` group. [^2]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L1466-L1469 [^3]: https://github.com/odoo/odoo/blob/6ba1106aecf71886b7df3b7943089fa72a6c506c/odoo/addons/base/models/res_users.py#L589-L599 Solution -------- Add a context value when calling `super().write`. If this value is present in the current call, this indicates we are in a recursive write, and can return without adding/removing implied groups, as these will get handled later by the base call. opw-4676929 Forward-Port-Of: odoo/odoo#207961
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been
Original PR description
*: l10n_cl, l10n_nz, sale_expense --- Description of the issue this commit addresses: [This PR](https://github.com/odoo/odoo/pull/211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211762 Forward-Port-Of: odoo/odoo#211609
Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel. This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it
Original PR description
Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel. This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float. To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing. Failing in Distro Build , python version >=3.10 raises a `TypeError` build_error-110207 Forward-Port-Of: odoo/odoo#210551
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the pa
Original PR description
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and…
Problem: For a gift card with 0 points which have its price changed a popup error is displayed saying the gift card has already been sold Steps to reproduce: - Install "point_of_sale" app and "pos_loyalty" module - Select "Scan existing cards" in the promotions settings - Generate a gift card with a value of 0.00 $ and copy its code - Start a shop session - Select the gift card product and enter the code - Change the price of the gift card (must be an integer < 10) - Proceed to the payment - See the popup error Cause: As the gift card has no points, `couponPointChanges` stays empty. But when the price is modified, `couponPointChanges` is updated but has no giftCardId so the error is triggered (see `validateOrder` in PaymentScreen.js). There is no issue if the price is > 10 or is not an integer because `_updatePrograms` is called after each click on the numpad and `changesPerProgram` gets the values of `couponPointChanges` which are the saved in `oldChanges` which is modified by getting the values of `pointsAdded` which has `giftCardId` so `couponPointChanges` get the `giftCardId` opw-3909019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#175232 Forward-Port-Of: odoo/odoo#174538
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. However, the current implementation does not properly handle this, with the default crone job running daily sending email reminders up to one day late. ### Current behavior before PR: Although the current implementation ensures the crone is not t
Original PR description
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo…
### Description of the issue/feature this PR addresses: When an event is synced with an external calendar (Google/ Microsoft), the external calendar is responsible for sending reminders, and Odoo should not send any additional reminders. However, the current implementation does not properly handle this, with the default crone job running daily sending email reminders up to one day late. ### Current behavior before PR: Although the current implementation ensures the crone is not triggered for alarms of external-calendars-synced events, the default crone job that is running daily is going all over the events with reminders need to be sent and send them up to one day late. ### Desired behavior after PR is merged: When the crone goes to trigger the _send_reminder method, it will check first if the events are synced or not, and if synced then no reminders will be sent from odoo's side. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr task-id: 4316693 Forward-Port-Of: odoo/odoo#211121 Forward-Port-Of: odoo/odoo#192876
Description of the issue/feature this PR addresses: The method action_add_from_catalog in purchase_stock replaces the product's kanban view with a purchase-specific one. This method directly replaces the first view in the list, which could be wrong if another module changes the default view of the catalog. This commit updates the method to replace only the kanban view, ensuring that other view types are preserved correctly. --- I confirm I have signed the CLA and read the PR guidelines
Original PR description
Description of the issue/feature this PR addresses: The method action_add_from_catalog in purchase_stock replaces the product's kanban view with a purchase-specific one. This method directly replaces the first view in the list, which could be wrong if another module changes the default view of the catalog. This commit updates the method to replace only the kanban view, ensuring that other view types are preserved correctly. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182918 Forward-Port-Of: odoo/odoo#175438
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
Original PR description
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with…
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs).
This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
According to the Fetch specification, the user agent may terminate an ongoing fetch if that termination cannot be observed through script. In our case, however, the fetch cannot be terminated because the termination can be observed through the promise and a TypeError is thrown[1].
Here a sample to reproduce the errors with firefox on github:
```js
window.onbeforeunload = () => console.log("beforeunload");
fetch("https://github.com/").then(() => console.log("fetch"));
window.location = "https://github.com/";
```
Should log inside the Firefox console:
```log
beforeunload
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
```
Another errors can occur when we unload a page, if we manipulate the DOM when it's unload a DOMException can be trowed[2], we also handle these case inside this commit.
This commit prevents displaying these errors on dialog inside Odoo.
task-4457865
[1]: https://fetch.spec.whatwg.org/#http-network-fetch
[2]: https://webidl.spec.whatwg.org/#dom-domexception-abort_err
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210854
Forward-Port-Of: odoo/odoo#210786Before this change, all quotations and orders were loaded into the same view in the POS frontend. This caused severe performance issues and even complete unresponsiveness when a large number of records were present. This commit introduces proper pagination for this view, limiting the number of displayed records to 80 per page to avoid bloating frontend memory and speeding up the fetch. ** Benchmarks:** | num records | before | after | |-------------|---------------------
Original PR description
Before this change, all quotations and orders were loaded into the same view in the POS frontend. This caused severe performance issues and even complete unresponsiveness when a large number of records were present. This commit introduces proper pagination for this view, limiting the number of displayed records to 80 per page to avoid bloating frontend memory and speeding up the fetch. ** Benchmarks:** | num records | before | after | |-------------|---------------------|-----------| | 17,000+ | frontend unresponsive | < 500ms | opw-4728862 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209038
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.co
Original PR description
Issue: In Odoo, it is impossible to generate an NLCIUS document for a partner with a valid Peppol endpoint using their Netherlands VAT (schemeID=9944) instead of a Dutch KVK/OIN identification number (schemeID=0106/0190). The latter is required for the PartyLegalEntity section of the document, but shares fields with the Peppol endpoint values, thus the two are incompatible. Solution: When the Peppol endpoint is not set to KVK/OIN, the number is instead taken from the generic res_partner.company_registration field which is used for similar purposes for other locales, and the length of the number is used to determine the type. Addresses ticket-4624350 task-4624366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209875
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
Original PR description
All instances of "_t" in emoji shortcodes were incorrectly replaced with "_lt" (e.g., "christmas_tree" became "christmas_ltree"). This commit restores the proper spelling. Forward-Port-Of: odoo/odoo#211741
*: account_sepa_direct_debit, l10n_ec --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's m
Original PR description
*: account_sepa_direct_debit, l10n_ec --- Description of the issue this commit addresses: [This PR](odoo#211150) has brought our attention to some files that were in the codebase but not included in their module's manifest. Therefore they are useless as is and can either be deleted or need to be put in the manifest. --- Desired behavior after this commit is merged: Unused useless files have been removed from the codebase. Unused useful files have been added to their module's manifest. --- task-4822341 Forward-Port-Of: odoo/enterprise#86471 Forward-Port-Of: odoo/enterprise#86397
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
Original PR description
…de for payslip display We increase the size of the external CH code to not impact payslip display Forward-Port-Of: odoo/enterprise#86299
**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#832
Original PR description
**Issue:** In a swiss company, when a user clicks on "Prepare Data" for a salary certificate rectification, an error occurs. **Steps to reproduce:** - make sure l10n_ch_hr_payroll_elm_transmission is installed and you're in a swiss company - Payroll > Transmission > Salary Certificate Rectification - create a new declaration and fill the form with a newly created previous declaration - click on "Prepare Data" A traceback is raised opw-4687938 Forward-Port-Of: odoo/enterprise#83261
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_i
Original PR description
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive…
…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals: https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88 While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record. opw-4627851 Forward-Port-Of: odoo/enterprise#85545 Forward-Port-Of: odoo/enterprise#83487
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution -------- Remove the `parent` checks. opw-4788215 Forward-Port-Of: odoo/enterprise#86384
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows w
Original PR description
Currently the SEPA mandate auto validation is done when the payment ref of the statement line is the same as the name of the payment transaction and that the partner id matches between SEPA mandate and statement line. Issue is that some flows (at least the bank synchronization handled through `account_online_synchronization` and odoofin) do not set the partner id on the bank statement line (until reconciliation) but provide it first through the `partner_name` field. To ensure those flows work fine with SEPA, we should also match transactions and statement lines whose partners names match when there is no partner_id set on the bank statement line. opw-4536189 Forward-Port-Of: odoo/enterprise#85965
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#76412 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#76412 Forward-Port-Of: odoo/enterprise#57781
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#66529 Forward-Port-Of: odoo/enterprise#57781
Original PR description
This enhancement introduces support for customer statements in the Indian localization of the accounting package. The update includes an automatic installation of the customer statement module, which essentially exports the partner ledger. Task link: https://www.odoo.com/web#model=project.task&id=3774149 task-3774149 Forward-Port-Of: odoo/enterprise#66529 Forward-Port-Of: odoo/enterprise#57781