Daily updates from Odoo
Tuesday, January 27, 2026
57 changes · saas-19.1
Enhancements to existing features
This update allows users to easily navigate to specific sections within Odoo's accordion items on the website. The changes automatically scroll to the selected accordion item and expand it, improving the user experience and making content more accessible. This enhancement was driven by a request to simplify navigation within complex information displays.
Original PR description
*=html_builder This PR introduces the following changes: - Add `.accordion-item` selector in the `AnchorPlugin`. - Expands the list of titleEls selectors to include `.h1-fs, .h2-fs, .h3-fs, .h4-fs, .h5-fs, .h6-fs, .display-1-fs, .display-2-fs, .display-3-fs, .display-4-fs, .base-fs, .o_small-fs`. - Enhances the "AnchorSlide" interaction by adding the "handleAccordionAnchor" method, called in "animateClick" and "setup" to automatically scroll to and expand accordion items. The method uses the `show()` function from bootstrap `Collapse` component, which efficiently manages the expansion of required accordion item and collapse the rest. task-5065165 Forward-Port-Of: odoo/odoo#226091
This update introduces the ability to temporarily 'snooze' products in the Point of Sale system. When a product is snoozed, it appears grayed out and unavailable for a set period (1-4 hours or session), visually indicating it's temporarily out of stock. This provides a way to manage product availability without permanently removing items from the system.
Original PR description
The PR will add an extra availability section on the product info popup which shows whether a product is currently available. From that section the product can then be 'snoozed', which will make it unavailable for a specified period of time. (1, 2, 4 hours, or for the entire session). When the product is unavailable there's a countdown timer on the popup showing when the product will be available again. Products which are 'snoozed' still show up on the product screen, but grayed out. The effect is purely cosmetic, as they can still be added to new orders. Task-[5170696](https://www.odoo.com/odoo/project/1737/tasks/5170696) Previous discussion-[#232625](https://github.com/odoo/odoo/pull/232625) Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update allows staff to temporarily hide products in the Point of Sale system by 'snoozing' them. When a product is snoozed, it appears grayed out on the product screen, but remains available for new orders. This helps manage stock levels and avoid overselling.
Original PR description
The PR will add an extra availability section on the product info popup which shows whether a product is currently available. From that section the product can then be 'snoozed', which will make it unavailable for a specified period of time. (1, 2, 4 hours, or for the entire session). When the product is unavailable there's a countdown timer on the popup showing when the product will be available again. Products which are 'snoozed' still show up on the product screen, but grayed out. The effect is purely cosmetic, as they can still be added to new orders. Task-[5170696](https://www.odoo.com/odoo/project/1737/tasks/5170696) Previous discussion-[#232625](https://github.com/odoo/odoo/pull/232625) Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the system administrator notifications displayed in Odoo Enterprise. It now allows for multiple messages with varying levels of urgency, providing more detailed and flexible alerts regarding server maintenance or other important events. This improves communication and allows for more targeted notifications.
Original PR description
Tweak #102239 to allow more flexibility and display multiple messages with different alert level.
The ir.config_parameter is sysadmin.message and should be a json loadable. The format shoud be something like this:
{
"replace": false,
"warning_type": "user",
"message": "<div class='alert alert-info'>A maintenance operation is planned on your server on <strong>2026-01-15</strong> between 14h and 15h</div>"
}
Forward-Port-Of: odoo/enterprise#105157Resolved issues and error corrections
This update resolves a crash that occurred when confirming purchase orders linked to multiple sales orders (grouped RFQs). The fix ensures that each purchase order is associated with only one sales order, preventing a data conflict. This improves the stability of the dropshipping process.
Original PR description
An error occurs when confirming a purchase order linked to multiple sales orders. Steps to reproduce: 1) Install sale_stock & sale_management and enable dropshipping. 2) Create a vendor with…
An error occurs when confirming a purchase order linked to multiple sales orders. Steps to reproduce: 1) Install sale_stock & sale_management and enable dropshipping. 2) Create a vendor with group_rfq 'always'. 3) Create a product with dropship route and add that vendor. 4) Create a Quotation with that product, confirm it, duplicate and confirm. 5) From the magic button go to Purchase Orders and confirm the PO. Reference video for steps : https://drive.google.com/file/d/1xglkuZAWNxcz0WSj_49Hemjkxx4KjSqv/view?usp=sharing Error: `ValueError: Wrong value for stock.picking.sale_id: sale.order(26, 27)` Root Cause: The computed field `sale_id` receives multiple `sale.order` records from `move_ids.sale_line_id.order_id` (see [1]). Since `sale_id` is a Many2one field, it can only accept one record or False. Assigning multiple records causes the error. Fix: * Create only one sale order per purchase order for drop-shipping picking types. For existing databases, set the value to the first available sale_id, or False if none exists. [1]- https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/sale_stock/models/stock.py#L175-L179 opw-5344535 Forward-Port-Of: odoo/odoo#237945
This update fixes an issue where users couldn't adjust the quantity of optional products added through the portal's upsell feature. The change ensures that the 'optional' status is correctly applied to new order lines, allowing users to accurately update product quantities and manage their subscriptions.
Original PR description
Version: - 19.0 Steps to Reproduce: - Enable the Add Products option in the recurring plan. - Create a subscription with the same plan and add optional products. - Confirm the subscription and create invoice for current period. - From the portal, click on Add Quantity to create an upsell order. Before: - Users were not able to update the quantity of products added as optional products from portal. - This happened because the `is_optional` field value was not copied to the new order line created during the upsell. After: - The `is_optional` field value is now copied to the new order line created for upsell and renewal orders. - This allows users to update the quantity of optional products correctly. Impact: - Users can update the quantity of optional products from the portal without issues. task-5427585 Forward-Port-Of: odoo/enterprise#102670
This update resolves a problem where toggling image captions caused layout disruptions, particularly when images were placed within tables or other non-paragraph containers. The fix ensures images remain correctly positioned within their original layout structure, improving the visual consistency of records.
Original PR description
Description of the issue this PR addresses: - When toggling an image caption, the logic only checks whether the image or figure’s closest block is editable. This causes images inside non-paragraph containers (such as table cells, list items, blockquotes, and columns) to be repositioned, breaking the original layout. Desired behavior after PR is merged: - Image caption toggling correctly handles paragraph-related containers, ensuring the image remains within its original structural context (tables, lists, blockquotes, columns) without altering the layout. Steps to Reproduce: - Open a to-do record. - Insert a table. - Add an image inside any table cell. - Toggle the image caption multiple times (3–4 times). task-5485697 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245227 Forward-Port-Of: odoo/odoo#243454
This update resolves an issue where users would encounter an error when creating inherited views. The fix ensures that a validation error is triggered if the XPath syntax is incorrect, preventing the application from crashing and improving the user experience when customizing views.
Original PR description
Currently, an error occurs when a user creates an inherited view. **Steps to Reproduce:** - Go to `Settings > Technical > User Interface > Views`. - Create a new view by entering `name` and selecting…
Currently, an error occurs when a user creates an inherited view.
**Steps to Reproduce:**
- Go to `Settings > Technical > User Interface > Views`.
- Create a new view by entering `name` and selecting any `inherited view`.
- In the `Architecture`, enter the below code:
```
<xpath position="replace">
<field name="name"/>
</xpath>
```
- Now save the view.
`TypeError: Argument must be bytes or unicode, got 'NoneType'`
Cause:
As we can see, when the user enters an xpath without the expr attribute, and when it goes to find the inherited node [1]. Since the expr is missing, its value becomes None [2]. Passing this None as an argument [3] causes the error.
This commit ensures that when a user creates or edits a view with an xpath that is missing the expr attribute, a ValidationError is raised indicating that the expr attribute is missing in the XPath.
[1]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L145
[2]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L76
[3]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/tools/template_inheritance.py#L78
[4]: https://github.com/odoo/odoo/blob/4876a54e8cfb3a115b5423db102fc2b7a40b196a/odoo/addons/base/models/ir_ui_view.py#L377-L384
sentry-7161414430
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#242203This update resolves an issue causing a 'NameError' in the TFN dashboard warning, preventing incorrect warnings from appearing for employees applying for TFN. The fix ensures the system correctly identifies and displays relevant warnings related to TFN status, improving payroll accuracy. This upgrade was necessary to maintain consistent reporting.
Original PR description
Steps to reproduce: ------------------- 1. Install l10n_au_hr_payroll. 2. Enable multi-company and switch to an AU company. 3. Change an existing employee’s company to the AU company ([employee…
Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.
Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.
Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.
**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.
opw-5459998
Forward-Port-Of: odoo/enterprise#103777This update enhances traceability for EDI and e-Way Bill requests by storing all request payloads as JSON attachments. This improves debugging, simplifies audits, and strengthens compliance efforts related to these important tax processes. Task 4896516.
Original PR description
Before this PR: - Request payloads sent for EDI and e-Way Bill generation were not persisted. making debugging and audits difficult. After this PR: - all EDI and e-Way Bill request payloads are stored as JSON attachments, ensuring better traceability, troubleshooting, and compliance support. Task: 4896516 Forward-Port-Of: odoo/odoo#241704
This update resolves a bug where overtime entries were being incorrectly generated and overlapping due to a flawed system for managing overtime rules. The fix ensures accurate overtime calculations and prevents overlapping entries, improving the reliability of attendance tracking.
Original PR description
STEP TO REPRODUCE:
------------------
0- Go to attendance > Configuration > Overtime Ruleset 1- Create the following overtime ruleset (all rules are paid and with the entry type overtime):
rule 1: timing rule on worked day with this timing : 0AM -> 8AM
rule 2: timing rule on worked day with this timing : 12AM -> 1PM
rule 1: timing rule on worked day with this timing : 5PM -> 12PM
2- Go to attendance > configuration > settings
3- Enable Time Management
4- ANd change the extra hours validation by automatically approved 5- create an employee and give to him this overtime ruleset 6- Create for an attendance for him from 6AM to 8PM 7- to go the form view of this attendance
8- Approve it; you wwill have a traceback
REASON:
-------
The way to handle the reorganization of the overtime line on an attendance was badly done; everything was shift with the same shift so some overtime was overlapping the others
Forward-Port-Of: odoo/enterprise#105173This update ensures that new partners created during shared sign requests automatically use the signer's name instead of their email address. Previously, the system defaulted to using the email as the partner name, which caused confusion and potential data inconsistencies. This change improves data accuracy and user experience.
Original PR description
Version: - saas-18.2 Steps to reproduce: - Create a shared sign request. - Open the shared signing link and complete the signature process. - During signing, a new partner gets created for the signer if not already exists. Before: - When the user signs the shared sign request and a new partner is created, the partner name is not set and email is used as name. After: - Now, when a user signs a shared sign request and a new partner is created, the system automatically sets the partner name using the signer name. task-5776339 Forward-Port-Of: odoo/enterprise#105271 Forward-Port-Of: odoo/enterprise#104869
This update fixes an issue where a specific error occurred when a leave request was linked to a refused allocation, triggering the 'Time Off: Cancel invalid leaves' cron job. The fix addresses a problem with how data was being accessed, preventing a traceback and ensuring the system handles refused allocations correctly.
Original PR description
When a leave is linked to a refused allocation and the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs. Steps to reproduce the error: - Install ``hr_holidays`` without demo data -…
When a leave is linked to a refused allocation and
the cron ``Time Off: Cancel invalid leaves`` runs, a traceback occurs.
Steps to reproduce the error:
- Install ``hr_holidays`` without demo data
- Create a new Time Off Type > Time Off Requests, Approval: No Validation >
Allow Negative Cap: True > Maximum Excess Amount: 2
- Create an Accrual Plan using default values
- Create a New Allocation
- Allocation Type: Accrual Allocation
- Set the Time Off Type and Accrual Plan created above
- Allocation: 1 day > Approve
- Create a new Time Off in the near future (in the current month) and select the Time Off Type created above
- Go back to the Allocation > Refuse
- Run the cron ``Time Off: Cancel invalid leaves``
Traceback:
``IndexError: list index out of range``
https://github.com/odoo/odoo/blob/bc5f24195a486112574900015ecbcf0e3ba32145/addons/hr_holidays/models/hr_leave.py#L1535-L1536
Here, ``leave_type_data`` becomes ``defaultdict(<class 'list'>, {})``
because when the allocation is refused and the cron runs,
the ``get_allocation_data`` method returns an empty defaultdict.
As a result, accessing the index leads to the above traceback.
sentry-6874651972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#243505
Forward-Port-Of: odoo/odoo#227201This update corrects a minor technical issue related to printer disconnection tracking. Previously, a specific device configuration caused a system error. The fix ensures accurate disconnection counts, improving the stability and reliability of the printer interface.
Original PR description
This commit fixes an edge-case between the disconnect counter logic, and the logic added in odoo/odoo#224200 to prevent printers switching between `lpd` and `socket` protocols. In this case, a device is returned that only has the `identifier` key set. Because the driver has already been instantiated, this didn't break anything before, but now it also clears the `disconnect_counter` key, leading to a traceback on the next iteration of the interface when it tries to check the `disconnect_counter`. The fix is simply to include the `disconnect_counter` as well. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245719
This update resolves a bug that caused the follow-up report to crash when users unfolded partner lines while prefix groups were enabled. The fix ensures the report correctly handles data retrieval, preventing a key error and improving stability for users.
Original PR description
When prefix groups were enabled, and a prefix group line had been unfolded, the report crashed when trying to unfold the partner. This happened because res_ids_map is computed for each of the unfolded lines, including the prefix groups one, which then had no 'res.partner' key, causing a key error. Forward-Port-Of: odoo/enterprise#105525
This update corrects an issue with how URLs are encoded in the website's sales functionality. The fix ensures that all necessary data is properly transmitted, preventing potential errors and improving the reliability of the sales process. This is a routine maintenance update.
Original PR description
Oversight of https://github.com/odoo/odoo/pull/238396 Calling `urlencode` with the result of `parse_qs` is incorrect, and requires `doseq=True` to work as expected. opw-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a visual glitch in the time-off UI for Belgian employees. Previously, sickness relapse fields appeared unexpectedly after approving time off. The fix adjusts the layout to properly position these fields, ensuring a consistent and user-friendly experience.
Original PR description
Bug production steps: Select employee works in Belgium company, go to timeoff and approve >= 1 months time off and select new timeoff after 1-2 days and there Sickness Relapse fields occur in the shifted UI. Bug cause: The field sickness_relapse added after attach file part, before there was label for the attach file part and it was occupying 2 columns, after removing column it occupies only 1 and the first part of the boolean sickness relapse fields come next to the attach file part. Bug solution: Make the colspan 2 for the attach file part, by that way the sickness_relapse will start from the below line. task - 5493425 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245605 Forward-Port-Of: odoo/odoo#243753
This update resolves a bug where enabling the 'Auto Crop' feature for product images in the online shop didn't actually crop the images as expected. The previous code was overriding the intended image settings, leading to a broken feature. This fix ensures that 'Auto Crop' now correctly adjusts the product image size.
Original PR description
Steps to reproduce: =================== 1- Go to website > shop & open edit mode 2- Select any product and click on "paint-brush" icon 3- Click on "Image ratio" option and enable "Auto crop" -> nothing happens to the images. Cause: ====== After this commit [1] `object-fit-contain` was used even for auto crop which will override the `o_wsale_products_opt_thumb_cover` class object-fit value. Solution: ========= Apply basic fit contain only when autocrop is disabled. [1]: https://github.com/odoo/odoo/pull/238108/commits/002a8a1ff65fd48fd69e41c9a881fddceee34bf5 opw-5868057 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245258
This update resolves an issue preventing NFC-e refunds from being processed correctly in Point of Sale. Previously, a technical error caused a 'not found' message when attempting to retrieve the original invoice. The fix ensures the system accurately identifies and uses invoice references during the refund process, enabling successful transactions.
Original PR description
**Steps to reproduce:**
- Setup a database that supports NFC-e
- Go to PoS, make a purchase, then refund it
- A traceback appears, saying we couldn't find the original invoice
**Why the fix:**
Before this commit the way we checked if there was already an invoice in the payload we give to the API was wrong, as it was always true. This happens because before the
*def _get_l10n_br_avatax_service_params(self):* call, we set res['invoice_refs'] as {}, then we were supposed to fill it. But if we check https://github.com/odoo/enterprise/blob/32b73b12f9f8f5600b820d9a938bfbb0cf10054d/l10n_br_edi_pos/models/account_move.py#L13 'invoice_refs' is found in res, even though it is empty, so we never entered the if statement.
We now check if there is a value in res['invoice_refs'] and if not we set it.
opw-5359407
Forward-Port-Of: odoo/enterprise#104987
Forward-Port-Of: odoo/enterprise#102770This update fixes an issue where the 'Inventory Reason' entered during barcode inventory counts wasn't being recorded in the system. Now, when completing an inventory count via the Barcode app, the specified reason is correctly logged in the Moves History, ensuring accurate tracking of inventory adjustments. This improves the reliability of inventory reporting.
Original PR description
## Issue When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere. ## Steps to reproduce 1. Install the *Barcode* app…
## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.
## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
- **The _Inventory Reason_ given in step 5 does not appear anywhere**
If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.
## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.
opw-5423934
Forward-Port-Of: odoo/enterprise#104763This update fixes a bug where tax return labels weren't correctly translated when a new language was installed. The system now automatically generates translations for all existing tax return labels upon language installation, ensuring consistent and accurate labeling across all supported languages. This improves the user experience for international users.
Original PR description
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to…
**Commit 1:** [FIX] account_reports: translation of account returns states Steps to reproduce: - Open the tax returns - Set an account opening date to generate some returns - Add another language to the database and select it -> The states of the returns (the little bubble in the kanban cards) aren't translated even though the translation is present in the pot and po files. **Commit 2:** [FIX] account_reports: translation of date in returns title Steps to reproduce: - Have 2 languages on the db - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Switch to the second language -> The period displayed in the name of each return isn't translated **Commit 3:** [FIX] account_reports: translate account returns name after lang installation Steps to reproduce: - Generate the tax returns by going to Accounting/Tax Returns and set the opening date - Install another language -> The names of the returns aren't translated in the new language. Solution: When installing a new language, generates the translation of the title for all existing returns task-5421659 Forward-Port-Of: odoo/enterprise#102559
This update addresses a limitation in the account online synchronization process where access tokens expire quickly. We've implemented a new consent token system – a unique, secure identifier linked to the user – to ensure reliable consent management and continued synchronization functionality. This change improves the user experience and data integrity.
Original PR description
In this commit:bf5b7d0 we introduce a message on the account_online_link to be able to manage the consent. (one needed fix in this commit:https://github.com/odoo/enterprise/commit/1c84804fd3f0c0d1d23916b9f6a388616f66ac7e) This commit will change the way we manage the consent since the access token is in fact available only for 30 min, so the link in the chatter would not work. We decided to have a consent token which is a uuid4 encoded in base64 (url safe) and link it to the odoofin user. task-5187621 Forward-Port-Of: odoo/enterprise#105392 Forward-Port-Of: odoo/enterprise#105202
This update corrects a compatibility issue with the Bulgarian National Bank (BNB) exchange rate provider. Due to Bulgaria joining the Eurozone, the BNB now provides rates in EUR, not BGN. This change ensures that companies using EUR as their main currency can correctly sync exchange rates without errors.
Original PR description
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the…
The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR. This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates. refs: We can compare the data here from 31 December using the WayBackMachine: https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm Compared to today: https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm And see the comparison used to be to BGN but is now for EUR Steps To Reproduce: 1. Create a company for Bulgaria with EUR as the main currency. 2. Go to Accounting Settings -> Automatic Currency Rates. 3. Select "[BG] Bulgaria National Bank" as the service provider. 4. Click the sync button. 5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one." The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR. Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO. Ticket [link](https://www.odoo.com/odoo/project.task/5483771) opw-5483771 Forward-Port-Of: odoo/enterprise#105074
This update fixes an issue preventing bookings from being scheduled for the last hour of the day in the appointment system. The previous code incorrectly treated the end of the day as an unavailable slot, blocking bookings. This change ensures that appointments can now be booked for the full 24-hour period, resolving a common user frustration.
Original PR description
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to…
**Steps to reproduce:** - Go to Appointment app - Edit an appointment type - Ensure its availability is on resources - Set duration to 1 hour - Add a schedule slot ending in 00:00 - Save and go to the website page of the appointment - Last slot is not showing (23:00-00:00) **Issue:** When computing the appointment slots of a resource using time range, the end of day is considered as an unavaibility resource slot with this interval in `_get_unavailable_intervals`: `i_start = 23:59:59.999999` `i_stop = 00:00` this conflicts with the given range (23:00-00:00) in `self._slot_availability_is_resource_available` It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)` is converted to `time.max` (23:59:59.999999) by: `day_to = datetime.combine(day, float_to_time(attendance.hour_to))` This introduces the microsecond unavaibility at the end of the day, which blocks the booking. (it's working properly for availability on users appointments) **Fix:** Changed the condition so that 23:59:59.999999 is considered as equal to 00:00. opw-5163892 Forward-Port-Of: odoo/enterprise#104927 Forward-Port-Of: odoo/enterprise#100853
This update fixes a layout issue where image gallery indicators become cramped with many images and improves the overall responsiveness of image carousels, particularly on Firefox. By preloading images and optimizing the loading process, the gallery now appears smoother and more reliable.
Original PR description
## [FIX] website: add versioning for GallerySlider interaction The GallerySlider interaction (and its edit mode counterpart) is not up to date: the logic is still written for old snippets (before…
## [FIX] website: add versioning for GallerySlider interaction
The GallerySlider interaction (and its edit mode counterpart) is not up
to date: the logic is still written for old snippets (before [9042b1c],
so before 18.0).
In the meantime, the pagination for the indicators was lost, meaning
that if you add too many images, the indicators will have less and less
space.
Steps to reproduce:
- Drop an Image Gallery snippet
- Set the indicators to squared or rounded miniatures
- Add 15 or more images
=> All the indicators are crammed into the same line.
With this commit, we deprecate the old `GallerySlider` interaction and
create a `GallerySlider001` for the snippets dropped since 18.0.
For the indicators, instead of a pagination, we now use a horizontal
scrolling container which centers on the active indicator.
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c
## [FIX] website: preload available carousel images
As images are lazy loaded, it means that in the context of a carousel or
an image gallery, they only start loading once the user clicks either on
its indicator or on the previous / next button (or after completing an
auto-slide). While Chrome seems to optimize that to make it seemless, on
Firefox this causes the carousel slide to appear blank for a moment
before the image suddenly pops up, as the sliding animation arrives to
its end.
In effect, this causes a flicker and a feeling that the carousels, and
especially the gallery, is extremely laggy.
To mitigate that while trying to keep the advantages of image lazy
loading, this commit partially backports [08d837e], which loads the
images of the next and the previous carousel items.
Additionally, we prefetch the target images on pointerdown / keydown on
an indicator. That may seem like too small of a difference to be
interesting, but it actually gives a little bit of time between the
pointerdown and pointerup (which triggers the slide event) to start
loading the images, which with a correct connexion already goes a long
way towards mitigating the laggy feeling.
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
task-5245513
Forward-Port-Of: odoo/odoo#245144
Forward-Port-Of: odoo/odoo#232147This update resolves an issue where the 'All Warehouses' placeholder in the product routing settings was misleading. Previously, it prevented users from correctly setting up reordering rules to prioritize specific warehouses. This change ensures the placeholder accurately reflects the functionality, allowing for proper route configuration and improved inventory management.
Original PR description
Update warehouse_ids placeholder ("All Warehouses") to a new placeholder that reflect its behavior.
### Steps to reproduce:
* Enable multi-Step Routes
* Inventory > Routes > Buy > Warehouses
* Select the checkbox but leave the field empty (placeholder says "All Warehouses")
### Steps to verify behavior:
* Leaving the warehouse_ids fields empty ("All Warehouses")
* Create a product tracked by quantity and add a vendor
* Create a Reordering Rule
-> It doesn't put the "Buy" route by default as it should
opw-5264571
Forward-Port-Of: odoo/odoo#245547This update fixes an issue where tooltip labels and help text appeared on the same line in tree views. The change ensures that tooltips now display with proper line breaks, improving readability and the overall user experience. This enhances the clarity of information presented within the Odoo application.
Original PR description
Tooltip `label` and `help` appear on the same line because the `o-tooltip--string` on the `help` make it display inline. Move `o-tooltip--string` to be on the entire component instead. reference comment: https://github.com/odoo/odoo/pull/243295#issuecomment-3742599307 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a display issue within the Coffee Break theme, specifically related to the presentation of social links. Previously, these links appeared on separate lines. Now, they are correctly aligned, ensuring a consistent and professional appearance for users. This improves the overall user experience.
Original PR description
This commit fixes a display issue with the coffeebreak theme. The new social links weren't correctly displayed, forming 2 lines instead of 1. Now they are all aligned. task-5868123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A bug was causing a multi-company error when generating offers for new applicants in the recruitment process. This fix created a specific demo data record for the 'Experienced Developer' role in Belgium, resolving the issue and ensuring correct offer generation for Belgian users. This was a backport of a previous task.
Original PR description
## Issue: When we go to recruitment and try to generate offer for a new applicant for job position 'Experienced Developer', it shows multi company error. ## Steps to reproduce: 1. Go to recruitment for US company 2. Make a new applicant for the position 'Experienced Developer'. 3. Then generate offer for that applicant, multi company error will come. ## Cause: The job was inherited and given `contract_template_id`. ## Fix: Made a new record for Belgium Job position 'Experienced Devloper(BE)'. backport of task-4885755 task-5445798 Forward-Port-Of: odoo/enterprise#104013 Forward-Port-Of: odoo/enterprise#102991
This update resolves an issue where country-based filtering within work entries wasn't functioning correctly, leading to errors. The fix ensures accurate country filtering, eliminating module loader errors and improving the usability of this feature.
Original PR description
Issue: The country_id related field on work entries was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter on field to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/odoo#243564 Forward-Port-Of: odoo/odoo#239573
This update resolves an issue where country-based filtering on payslips and payslip runs wasn't functioning properly, leading to errors. The fix ensures accurate country filtering, preventing module loading problems and improving the reliability of payroll reporting.
Original PR description
Issue: The country_id related field on payslip and payslip run was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/enterprise#104167 Forward-Port-Of: odoo/enterprise#103318
This update adds a 'View' button to the package history list, allowing users to directly access the associated package records. Previously, users couldn't open these records from the package history, which has now been resolved to improve tracking and management of stock packages. This enhancement streamlines the process of reviewing package details.
Original PR description
Steps to reproduce: - Enable packages - Do a reception with a product and put it in a pack - Open the 'Packages' stat button - View button is at the end of every line, to open the package - Go back to the picking and validate it - Open the 'Packages' stat button again Issue: There isn't any 'View' button, so we can't open the package records from here. It was done somewhat on purpose, as it's a list of `stock.package.history` and not `stock.package`, so we wouldn't open the right record. But we can simply add a button that opens the linked package instead. opw-5436847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245238
This update ensures that employee leave dates are automatically recalculated when their working schedule (calendar) changes. Previously, changes to an employee's schedule didn't correctly update their leave entitlements. This fix maintains accurate leave tracking for employees with dynamic work calendars.
Original PR description
purpose: Accepted leaves should be recomputed upon working schedule change. - made the `resource_calendar_id` change on the leave when it's changed on the corresponding employee/contract, then forced recomputation of its dates from the new resource calendar task-id: 5424312 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243425 Forward-Port-Of: odoo/odoo#241284
This update resolves a bug that prevented the Gantt chart from correctly rescheduling tasks when using Date fields instead of DateTime fields. The fix ensures that the Gantt chart can now handle rescheduling tasks with Date fields, improving usability and flexibility for project management. This was caused by a previous limitation in the system.
Original PR description
…atetime
Steps to reproduce
==================
- Install web_studio,project
- Open a project task
- Open studio
- Add a new Date field in the form view
- Switch to the gantt view
- Change the Start Date Field to the newly create Date field
- Exit studio
- Open a task
- Set a value for the date field
- Switch to the gantt view
- Drag the record
```
start_date_field_name in vals and datetime.strptime(vals[start_date_field_name], '%Y-%m-%d %H:%M:%S')
^^^^^^^^
ValueError: time data '2025-12-22' does not match format '%Y-%m-%d
```
Cause of the issue
==================
Since https://github.com/odoo/enterprise/pull/84820 , it only works for DateTime fields
opw-5345470
Forward-Port-Of: odoo/enterprise#103068This update resolves an issue where image selections in the website builder were not consistently updating across related components. The fix ensures that the correct image element is always used when processing snippets, resulting in a more reliable and accurate website design experience. This improves the overall user experience when adding images to the website.
Original PR description
[FIX] html-builder, *: update snippet at each snippet dropped handler *: website In the `ImageSnippetOptionPlugin`, at the `on_snippet_dropped_handlers` call, the `snippetEl` received as argument is replaced by the image selected by the user in the media dialog. The problem is that the call to subsequent handlers is done with `snippetEl` that is not an element of the DOM anymore. This commit fixes this by updating `snippetEl` if needed after each call to a `on_snippet_dropped_handlers` handler. task-5785233 Forward-Port-Of: odoo/odoo#245594 Forward-Port-Of: odoo/odoo#243766
This update fixes a critical accounting error related to Deferred GST (DGST) reporting in Australia. By reversing the tax rate, the system now correctly identifies DGST as a liability, ensuring accurate financial reporting. The changes also improve the display of BAS statements and add support for a key reporting line.
Original PR description
Prior to this commit, the Deferred GST (DGST) tax was configured with a positive rate. When applied to a Vendor Bill, this generated a Debit entry, incorrectly treating the tax as a Receivable rather…
Prior to this commit, the Deferred GST (DGST) tax was configured with a positive rate. When applied to a Vendor Bill, this generated a Debit entry, incorrectly treating the tax as a Receivable rather than a Liability to the ATO. This commit corrects the accounting and reporting logic by: - Inverting the tax rate: The tax now generates a Credit entry on Vendor Bills, correctly recording the Deferred GST as a liability in the General Ledger. - Adjusting BAS formulas: Updated the formulas for labels 7 and 7A to display a positive liability amount on the statement following the change in 1. - Adding Label 7A: Added support for the Deferred GST (7A) line to BAS variations where it was missing. - Reordering WET: Updated the Wine Equalisation Tax (WET) sequence so it no longer appears at the top of the list, as it is not applicable to all businesses. Task-5870092 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245368
This update resolves an issue where negative lines on invoices generated for Ecuador (l10n_ec) were not correctly formatted in the XML export. The change aligns the process with Mexico (l10n_mx) to accurately distribute discounts and avoid rounding discrepancies, ensuring accurate tax calculations and invoice generation.
Original PR description
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can…
In **l10n_ec**, negative lines are not accepted in the XML. They must be dispatched as discounts on positive lines. The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased. ## Steps to reproduce With **l10n_ec**: 1. Change the decimal accuracy to 6 digits. 2. Set the rounding method to *global rounding*. 3. Create an invoice with the following lines: | Quantity | Price | Taxes | |-----------|----------|-----------| | 20 | 1.4235 | VAT 0% G | | 20 | 1.6425 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.2337 | VAT 0% G | | 20 | 1.4235 | VAT 0% G | | 6 | 3.747768 | VAT 15% G | | 6 | 3.747768 | VAT 15% G | In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`. This happens due to rounding differences in how the `descuento` is computed in the `common_details_info_template` from **l10n_ec_edi**: format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount']) where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere. This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**. Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed. opw-5128612 Forward-Port-Of: odoo/enterprise#104659 Forward-Port-Of: odoo/enterprise#97337
A bug was preventing manufacturing administrators from completing work orders. This update adds sudo access to the failing process, ensuring these users can correctly finalize production tasks. This resolves a workflow issue and improves the usability of the manufacturing module for key personnel.
Original PR description
Steps to reproduce:
Create a user with admin access rights for Manufacturing and Quality only. Then, create a work center that has a cost per hour.
Create a product that has a BoM and create a MO then confirm it.
Add a work order that takes place in the created work center and has duration of 60 mins.
Using the created user, try to "Produce All".
Issue:
The user gets an access error when trying to "Produce All", eventhough they have manufacturing access rights.
Fix:
Add sudo access where the process fails to ensure that the workflow is as expected.
Note: a test will be added in anoher PR
opw-5480608
Forward-Port-Of: odoo/enterprise#104897This update fixes a bug where the sitemap generated for eCommerce categories included products that were marked as archived. The system now correctly filters out categories containing only archived products, ensuring the sitemap accurately reflects the live, active products available for sale. This improves the accuracy of our website's sitemap and helps search engines prioritize the correct products.
Original PR description
To reproduce:
- Connect as "admin"
- Go to "Website / eCommerce / Products / eCommerce Category"
- Create a new category "Test With Archived Products"
- Go to "Website / eCommerce / Products"
- Create a product:
- name it "Test Archived"
- in "Sales" tab, under "eCommerce Shop" section, set category to:
"Test With Archived Products"
- then archive the product
- Clear the sitemap attachment and go to /sitemap.xml
The sitemap has an entry for "Test With Archived Products" but it should should not be visible as there are only archived products for that category.
Since odoo/odoo@d3fd767b0568, access rules domain are always optimized with `active_test=False`, so ensure we only return public category that have active products.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236256This update ensures the Helpdesk dashboard's styling is consistent with other Odoo dashboards. Specifically, the conditional formatting for the Top Customers pivot has been extended to include all rows, and border styles have been aligned. This improves the overall visual appearance and user experience.
Original PR description
## Description - The Top Customers pivot shows 10 rows, but the conditional format covered only 9. Extend the CF range so the last row is formatted. - Adjust border ranges so the helpdesk dashboard matches the styling used in other dashboards. Task: [5448434](https://www.odoo.com/odoo/project/2328/tasks/5448434) Forward-Port-Of: odoo/enterprise#103793 Forward-Port-Of: odoo/enterprise#103019
This update fixes an issue where pricelist rules weren't correctly applied to product variants. Previously, rules only worked when editing in 'expanded' mode and would reset the display name. Now, when a variant is selected, the pricelist rule is properly applied, ensuring accurate pricing in sales quotations. This improves the reliability of pricing calculations.
Original PR description
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is…
Description of the issue/feature this PR addresses: - A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode - This is because the `applied_on` field is missing on the `product.pricelist.item` form view. Current behavior before PR: - Install `sale_management` - Enable "Pricelist" setting - Go to Sales - Products - Pricelists and create a new "Sample" Pricelist. - Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" /> - Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" /> - Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" /> - Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" /> - Same thing for second rule <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" /> - Create a new sale quotation with pricelist set to our "Sample" - Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" /> - Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" /> - Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" /> Desired behavior after PR is merged: - Each variant must have its own price. - The added test simply edit the pricelist item using its own form. - The `applied_on` field is added to the pricelist item form to ensure that its value is saved. - If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column. _Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?). But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`. _Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` .... --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245603 Forward-Port-Of: odoo/odoo#245444
This update resolves a minor rounding discrepancy in the calculation of withholding taxes for AR transactions. Specifically, the withholding amount was slightly off, resulting in a difference of 0.01. The fix ensures accurate tax calculations for purchases, improving financial reporting precision.
Original PR description
Steps to reproduce: - Set company to (AR) Responsable Inscripto - In Accounting > Settings, choose Round per Tax as the rounding method. - Go to Accounting > Taxes, duplicate IIBB WTH CABA 0%, and set Amount to 4.5%. - Open partner ADHOC SA, in the accounting tab add the new tax in Purchase Withholding - Create a new vendor Bill to vendor ADHOC SA with unit price 156,087.00 - Confirm and open Payment wizard Issue: Withholding amount is 7023.91, but it should be 7023.92 It occurs that the computed amount is 7023.915. Then when the tax repartition values are computed, the value is rounded and rounding difference are redistributed in the tax lines, so it seems the value has been rounded down. opw-5154585 Forward-Port-Of: odoo/odoo#241633
This update resolves a problem where the VoIP demo tour wasn't functioning correctly with the standard demo data. The code was adjusted to ensure the correct contact and activity are selected during the tour, and the tour file was moved to the appropriate location for better organization.
Original PR description
Make sure we select correct contact/activity when with demo data. Also move the tour to correct file.
This update resolves a potential error that could occur during the uninstallation process when an `ir.model.data` record has a zero `res_id`. The fix adds a filter to ensure only valid record IDs are processed, preventing a traceback and ensuring smoother uninstallation workflows. This improves stability and reliability.
Original PR description
linked to https://github.com/odoo/odoo/pull/245469, there is another case in the uninstallation flow that can raises a traceback in case of a `ir.model.data` where `res_id = 0` This commit adds an…
linked to https://github.com/odoo/odoo/pull/245469, there is another case in the uninstallation flow that can raises a traceback in case of a `ir.model.data` where `res_id = 0`
This commit adds an additional filter to the domain used to browse `ir.model.data` in `_module_data_uninstall` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.
One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```
This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)
This fix will avoid any additional traceback like this one.
opw-5865316This update resolves a technical issue causing performance problems in the Mail app. Previously, field updates across tabs were creating a loop, leading to slow performance and potential system freezes. This fix prevents unnecessary updates to local storage, ensuring smoother and more reliable field synchronization.
Original PR description
Diccuss fields have a `localStorage` option. The field updates via the `onUpdate` function in the current tab and writes to the local storage. Other tabs use the `storage` event to update their field. This pattern can cause race conditions, leading to loops, high CPU usage, and freezes. When a tab receives a storage event, it may write back an outdated value, triggering further writes and conflicts across tabs. This commit ensures we don't trigger `storage` events recursively: upon the reception of a `storage` event, field is updated but local storage is untouched. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where new partners, particularly those in EU countries, were incorrectly assigned a specific pricelist. Previously, all partners received a default pricelist, even when it matched the standard one. This change ensures that EU partners automatically use the standard pricelist, simplifying pricing and eliminating manual assignments.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4.…
Versions -------- - 18.0+ Steps ----- 1. Have a way to check the `specific_property_product_pricelist` field; 2. create a pricelist for EU countries; 3. delete all other regional pricelists; 4. create a new partner in a EU country; 5. create a new partner outside a EU country; 6. create a new partner without a country. Issue ----- Inconsistent behavior: - EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`. - The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them. Cause ----- In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it. Solution -------- Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`. > [!Note] > An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states: >> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view. > > This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`. opw-5385213 Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test) Forward-Port-Of: odoo/odoo#245681 Forward-Port-Of: odoo/odoo#241736
This update corrects a discrepancy in a sales subscription test. The test previously incorrectly prioritized pricelists based on default partner settings. The fix ensures consistent pricelist ordering, resolving a minor issue that could have affected subscription pricing calculations. This change improves test reliability.
Original PR description
Versions -------- - 18.0+ Issue ----- Commit a840e4250666 changed a `sale_subscription` test as pricelist ordering was changed. Before, it was `sequence asc, id desc`, now it is `sequence asc, id asc`. However, in the updated tests, it expects the first pricelist created with sequence 4 to be before the second pricelist with sequence 2. This was only happening due to default pricelists getting set as the `specific_property_product_pricelist` if the partner has no country assigned to them. Solution -------- As the behavior is now identical for partners with or without a country assigned to them, we can resolved the test setup by giving both pricelists an identical sequence, making the ordering fall back on `id` like a840e4250666 intended. opw-5385213 Related: https://github.com/odoo/odoo/pull/241736 Forward-Port-Of: odoo/enterprise#105475 Forward-Port-Of: odoo/enterprise#103116
This update fixes a technical detail related to the translation of Odoo's Greek language support. The incorrect language code ('gr') was replaced with the correct code ('el') in several configuration files. This ensures accurate translations and proper functionality for Greek-speaking users.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245617 Forward-Port-Of: odoo/odoo#244684
This update corrects a critical issue where newly added modules to the Odoo Enterprise stable release were not properly included in the translation files (.weblate.json). This meant that the Greek language version of the software was unavailable. The fix adds the necessary module definitions to the .weblate.json file, guaranteeing proper translation support.
Original PR description
Modules added into stable without being properly added to .weblate.json file = never translatable. Forward-Port-Of: odoo/enterprise#105413 Forward-Port-Of: odoo/enterprise#104890
This update fixes a bug where customers exceeding their credit limits in the Point of Sale (PoS) system weren't receiving warnings. The fix ensures that the system accurately calculates order totals and displays appropriate alerts when a customer's spending exceeds their established credit limit, improving financial control.
Original PR description
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it…
Steps to reproduce: ------------------- 1. Install pos_settle_due and accountant 2. In Accounting settings, enable "Sales Credit Limit" 3. Create a new customer, enable its "Partner Limit" and set it to 100 4. Open PoS, select that partner, and select products such that the total exceeds 100 Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page. Why the bug ----------- In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend. The fix ------- Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`. opw-5489975 Forward-Port-Of: odoo/enterprise#104591
This update resolves several minor issues within the IoT driver component of Odoo. Specifically, it prevents logging errors when exceptions occur, shortens a debugging token to avoid problems, and clarifies communication types for actions on the IoT device. These changes ensure smoother operation and stability of the IoT integration.
Original PR description
This PR adds minor fixes 1) We avoid logging the receipt in case of exception 2) We trim the remote debug token to avoid errors. 3) We add the communication type (websocket/controller) for actions on the iot box task-5881030
This update addresses a confusing warning displayed on voice channels when users didn't have camera permissions. The fix ensures that the camera button isn't highlighted in red or with a warning unless the channel is specifically set up for video conferencing. This simplifies the user experience and avoids unnecessary alerts.
Original PR description
Only channels that have cameraPermission of `prompt` should show the red and warning. If the permission is `denied` or `granted`, no badge should be shown. task-5263066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236297
This update fixes a technical issue where subcontracting manufacturing orders (MOs) were sometimes incorrectly identified as having multiple destination receipts. Previously, older versions of the system could create MOs with multiple receipt destinations, leading to a single destination being recorded. This change ensures accurate tracking of subcontracting MOs, resolving a potential data inconsistency.
Original PR description
Since commit fc66e2d4eb638f1486e69cd5920f02c787055da1 , a subcontracting MO only has one destination receipt. However, Subcontracting MOs created in previous versions can still have multiple move_dest_ids, hence `is_subcontract` must be accessed in a filter or after an `ensure_one()` OPW-5493343 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243742
This update enhances the monitoring of our AI usage by changing key logs from 'debug' to 'info', making them easier for our team and database administrators to track. Additionally, the system now accurately reports token usage from the LLM providers, resolving an issue where previous estimates were significantly inaccurate.
Original PR description
In this commit we change some important llm api usage logs from debug to info so they can be more easily monitored by us and database admins. We also change the usage reporting from a naive estimation (which greatly under-reported the token usage) to the actual token usage given to us by the LLM prodivers in the response. Forward-Port-Of: odoo/enterprise#105364
This update resolves an issue preventing electronic invoices in Latin American countries (Argentina, etc.) from printing correctly. The fix ensures that invoice headers and footers are dynamically generated based on the customer's fiscal country code, rather than relying on outdated chart templates. This guarantees accurate invoice formatting for all users.
Original PR description
This commit fixes a bug introduced here https://github.com/odoo/odoo/commit/3f7d79731fd5e5a751f7f1aeae63379c6211de5c because some old databases do not have set the chart template so it is needed to render the header and footer of the report template layouts taking in consideration the account fiscal country code instead of the chart template. Replicate printing the pdf of a customer electronic invoice on an argentinen company without chart template. Ticket Adhoc side: 105739 Task latam: 1373 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244102 Forward-Port-Of: odoo/odoo#238033
This update resolves a potential issue where tracking numbers in the POS Self Order module could collide. Because we couldn't add new fields directly to the main Odoo version, a simple method was used to generate unique tracking numbers by adding a random letter prefix. This ensures order tracking remains accurate and reliable.
Original PR description
Since we cannot add fields in stable we use a little trick to avoid collisions in tracking numbers for POS Self Order module. We do a modulo operation on the ID of the PoS config to select a random letter from A-Z and prepend it to the tracking number. Forward-Port-Of: odoo/odoo#245476
This update resolves an issue where gift cards were being printed repeatedly during point-of-sale transactions. Now, gift cards are only printed once when initially created, streamlining the process and preventing unnecessary printing. This improves efficiency and reduces potential printing costs.
Original PR description
*: pos_loyalty Gift card are now printed only one time at the creation not after each use. Forward-Port-Of: odoo/odoo#244089