Daily updates from Odoo
Tuesday, January 27, 2026
110 changes
31 changes
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
Resolved issues and error corrections
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 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 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 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 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 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 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 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 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
9 changes
Resolved issues and error corrections
This update resolves a technical issue causing a 'NameError' in the TFN dashboard warning, preventing incorrect warnings from appearing for employees applying for TFN. The fix ensures the warning calculation accurately identifies employees meeting the criteria, improving payroll reporting accuracy. This upgrade is part of the standard Odoo 18.4 release.
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 resolves a technical issue that could cause errors when processing Peruvian electronic invoices (PE DI) within Odoo Enterprise. The fix ensures that the system handles cases where invoice data is missing, preventing unexpected tracebacks and improving the reliability of the invoicing process. This ensures smoother and more accurate invoice generation and submission for our Peruvian clients.
This update addresses a limitation in how users manage their consent for online synchronization. Previously, a short-lived access token caused issues with the consent link in the chat interface. Now, a more stable consent token is used, linked to the user, ensuring a reliable process for granting access.
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 fixes an issue preventing appointment bookings from showing correctly at the end of the day. The system was incorrectly interpreting the end of the day as an unavailable slot, blocking bookings that started at 23:00. The fix ensures that the end-of-day slot is properly recognized, allowing for bookings to be scheduled until 23:59:59.
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 automatically matches bank statements with invoices when the reference information is identical. Previously, the system prevented this match, requiring manual intervention. This change ensures faster and more accurate reconciliation of bank statements, streamlining financial processes.
Original PR description
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also…
The aim of this commit is to make the automatic reconciliation works in case of an obvious matching that was prevented because the reference of the invoice was also it's payment reference. It also modify a docstring of a test because it was lying about what it was really testing. The usecase it says it forbid is actually enforced by `test_matching_algorithm_for_multiple_invoices`. ### Before this commit: - functionally: The obvious matching was denied and the accountant had to manually make the match. - technically: The `aml.ref` and the `move.payment_reference` were the exact same and thus postgres regrouped the invoice (through aml) with itself as if there were 2 invoices matching the same word. ### After this commit: - functionally: The obvious match is made. - technically: The initial intend was to avoid having several invoices (proxy by amls) reported for a specific matching word preventing the system to take a difficult and arbitrary functional decision which might be wrong. In order to comply with that and to not block the match of an invoice that would be matched through several matching words, we don't gather twice the same aml for the same word. task-id: None (The issue arose on odoo.com and was brought by APFA)
This update resolves an issue where users with limited sign rights couldn't access the sample document template. The fix ensures that users can create and manage sign items for the copied template, allowing them to successfully use the sample. This improves the user experience for all users.
Original PR description
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our…
**Issue** Users without 'Admin' Sign rights could in some cases not access the sample template. **Steps to reproduce** 1. Go to 'Templates' and archive the existing one in order to have the 'Try our sample document' shown and click on it. 2. Add some sign items to the template, and send it for a signature request. 3. With an user having only 'User: Own Templates' Sign rights, go to 'Templates' and click 'Try our sample document'. Access Error: Blame the following rules: - sign.item: group_sign_user: Create and manage template items **Cause** When the template has an associated sign request, it is copied. The problem is that the user currently doesn't have enough rights to create sign items for the copied template: https://github.com/odoo/enterprise/blob/2e8fb2ca274a0cf15d7b78a663bffe9cbb700153/sign/security/security.xml#L92-L101 **Change** Change the `user_id` of the new template to allow creating the sign items for it. opw-5254566 Forward-Port-Of: odoo/enterprise#102227
This update resolves a technical problem in the demo data for the Mexican payroll modules. Previously, the demo company name was being overwritten, causing issues with invoice and payment processing (CFDI stamping) within the demo environment. This change ensures the demo data accurately reflects the company and partner information.
Original PR description
The demo data of the Mexican payroll modules was overriding the company and partner name during installation, which can break the CFDI stamping flow for invoices and payment complements in demo databases. Forward-Port-Of: odoo/enterprise#103870 Forward-Port-Of: odoo/enterprise#102558
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 corrects an error in how the report processed data, ensuring stability and reliable report generation for all 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 resolves a problem in the payroll testing process where contract end dates weren't being calculated correctly. The fix ensures contracts automatically end after two years, aligning with standard payroll practices. This improves the reliability of payroll calculations and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` runbot-237945 runbot-237894
12 changes
Enhancements to existing features
This update expands Odoo's language support to include Spanish, recognizing the significant number of Spanish speakers. By adding Spanish translations, we improve the usability and accessibility of the software for a wider customer base. This enhancement aligns with our commitment to global reach and customer satisfaction.
Original PR description
The official language is English, but Spanish is spoken by ~41 million. task-5247124 Forward-Port-Of: odoo/odoo#245358
This update adds Spanish translations to the Odoo Enterprise platform, recognizing the significant number of Spanish speakers. This improves the user experience for a large potential customer base and expands Odoo's reach. It’s an important step in supporting global business needs.
Original PR description
The official language is English, but Spanish is spoken by ~41 million. task-5247124 Forward-Port-Of: odoo/enterprise#105246
Resolved issues and error corrections
This update corrects a technical issue that was causing an error message to appear on the TFN dashboard, specifically related to employee TFN status reporting. The fix ensures accurate warning calculations for employees applying for TFNs, improving payroll reporting reliability. This resolves a potential data discrepancy.
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 resolves an issue in Odoo Studio where incorrectly configured related fields could cause warnings and errors. The change ensures that Studio only creates relational fields with searchable data types, preventing these technical problems and improving stability for business users. This resolves a previous operational issue.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158
This update fixes an access error that prevented users with standard inventory permissions from generating serial numbers for tracked products. The issue stemmed from a specific write operation within the system's serial number generation process. The fix ensures that users can correctly generate serial numbers without encountering access restrictions.
Original PR description
**Behavior:** Behavior: When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error. This…
**Behavior:** Behavior: When logged in as a user with group_user access (member), trying to generate the next few serial numbers for a tracked product from receipts will cause an access error. This happens because there is a write operation on the ir.sequence linked to the serial number at the end of the process that happens only when the 'New' button was previously pressed. And since access rights to ir.sequence are dependant on the base group of the user, changing the user Inventory rights to admin will not resolve the issue. A test has been created to ensure no access error is created when generating sequence numbers as a lower access user, this test would pass without the fix since it is focused on the python function. **Steps to reproduce:** - Create a product that is tracked by serial number - Log in as a user with group_user access (member role) - Go to Inventory -> Operations -> Receipts - Create a new picking and add the product - After clicking on Mark as Todo you'll see Details pop up in the product line - After clicking Details, select Generate Serial/Lots - Click New, then Generate, and you'll get an access error for ir.Sequence opw-5368553
This update resolves errors in the SAF-T export process for Romanian companies when partner information (country or name) is missing. The fix ensures accurate invoice generation and SAF-T file creation by correctly handling missing partner details, specifically the RegistrationNumber format.
Original PR description
Fix SAF-T export errors when partners have no country or name. For Romanian companies, the RegistrationNumber should be generated as “04 + partner ID” for customers not subject to VAT and with unknown CNP, without including the country code. Steps to reproduce country issue: - Configure a Romanian company with l10n_ro_saft installed - Create a contact without a country - Create and validate an invoice for this contact - Export the SAF-T file from the General Ledger report You you will get a TypeError because you cant concatenate Bool and String. Steps to reproduce name issue: - Create a main contact - Add a child contact without a name - Change the child type to “Company” - Create and validate an invoice - Export the SAF-T file from the General Ledger report This prevents KeyError when printing the first 70 characters of the partner name in the report. opw-5499918 Forward-Port-Of: odoo/enterprise#105406 Forward-Port-Of: odoo/enterprise#105020
This update resolves an issue in Odoo's Web Studio where it could incorrectly link fields, leading to warnings and errors during setup. The change ensures that related fields are only created when linked to searchable fields, improving stability and preventing potential problems in business workflows. This resolves a technical issue impacting Studio's reliability.
Original PR description
Before this commit studio allowed to make a related field with a non-searchable field (ie standard computed fields) in the the chain. This triggered a warning at creation (at fields.py:resolve_depends) and errors when using in a business setting. After this commit, the filter to build the relational field is modified to take into account this. opw-5436158
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 handles complex data structures correctly, improving stability and reliability for users generating these reports.
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 resolves a bug in the website editor that occurred when users manipulated the page, leading to incorrect selection offsets. Specifically, clicking on blank spaces could cause errors. The fix ensures that selection offsets are validated, preventing these errors and improving the stability of the website editor, particularly in Chrome.
Original PR description
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing…
**Description of the problem** In the website editor, the user can manipulate the page in such a way to generate a problematic `SelectionPlugin.activeSelection`, which still points to an existing `anchorElement`, but has an invalid `offset`. **How to reproduce** This seems to be reproducible only on Chrome. 1. Enter in the website edit mode 2. Drop the `s_newsletter` snippet 3. Drop the `s_popup` snippet 4. Click on the popup, and delete it 5. Click on the blank space inside the `s_newsletter` snippet 6. Delete the `s_newsletter` snippet 7. The error occurs Notes: 1. Snippet different than `s_newsletter` can be used to reproduce the problem, as long as they contain a blank space. 2. It is important to make sure that the movement of the mouse pointer does not trigger any preview when going from step 5 to step 6. **Why the problem happens** On Chrome, clicking on a blank area can cause `document.getSelection()` to return a selection with a null `anchorNode.` When this happens, `SelectionPlugin.getSelectionData()` will use the already existing `activeSelection` if `activeSelection.anchorNode` is still connected. Before this commit, this method only checked that `anchorNode` was connected, without validating offsets. This leads to the following edge case: 1. The user removes the `s_popup` 2. At this point, `document.getSelection()` would point to the `s_newsletter` snippet, so if the user just deletes the snippet nothing bad would happen. But instead, if: 3. The user clicks on a blank area in `s_newsletter`, `document.getSelection()` will now return a null `anchorNode` 4. The user delete the `s_newsletter` snippet, and `SelectionPlugin.getSelectionData()` is called by an handler after the deletion 5. At this point: `document.getSelection()` has a null `anchorNode`, so the method will check if `activeSelection.anchorNode` is still connected, WITHOUT validating the offsets. 6. Since `anchorNode` is still connected, this selection will be used, and an error will be triggered shortly after, because the offset is too high (pointing to `s_popup` which does not exist anymore). **Fix** After this commit, when `SelectionPlugin.getSelectionData()` checks that `activeSelection.anchorNode` is still connected it also checks that the offsets are valid (meaning that they are smaller than the number of nodes). task-5430500 Forward-Port-Of: odoo/odoo#244331
This update fixes a rounding error in the calculation of withholding taxes for Argentine businesses. Specifically, the withholding amount was slightly off, resulting in a discrepancy. The change ensures accurate tax calculations for purchase withholdings, improving financial reporting accuracy.
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 an issue where customer invoices sent via Peppol were generating duplicate attachments, causing clutter in the system. The fix ensures that attachments are updated instead of created again, streamlining the invoice process and improving the user experience. This prevents confusion and ensures consistent attachment management.
Original PR description
When sending a customer invoice via Peppol, the system creates duplicate attachments (4 instead of 2 expected), cluttering the chatter and the attachment sidebar. This commit: - Implements a search-and-update logic for attachments to ensure idempotency (updates existing instead of creating duplicates). task-5438951 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#245370 Forward-Port-Of: odoo/odoo#241130
A previous issue prevented users from adding attachments when sending emails to large contact lists (501+ contacts). This update corrects a technical error related to how the system handles large contact selections, ensuring attachments can now be successfully added during mass email campaigns. This improves the reliability of the email sending process.
Original PR description
Steps to reproduce: 1. Install 'contact' 2. Create 501+ contacts (e.g. by duplicating existing one) 3. Select all contacts in list view and click Send Email (from Action menu) 4. Try to add an attachment Issue: - A traceback is raised in the mail composer: `SyntaxError: Unexpected end of JSON input` Cause: `res_ids` is not set on the composer when more than 500 records are selected. This is expected, as the compute method `_compute_res_ids()` does not write `res_ids` when the number of active_ids exceeds 500 (to avoid storing large payloads on the field). Because of this, the code trying to JSON.parse(res_ids) fails. see: https://github.com/odoo/odoo/blob/abc8417413faf598fb83106de4328571d71888aa/addons/mail/wizard/mail_compose_message.py#L400 Solution: - Fallback to context.active_ids when res_ids is not available opw-5351374 Forward-Port-Of: odoo/odoo#238311
5 changes
Resolved issues and error corrections
This update corrects a technical error in the l10n_au_hr_payroll module that was causing a warning message to appear incorrectly on the TFN dashboard. The fix ensures accurate reporting of TFN status for employees, preventing potential confusion and compliance issues. This resolves a bug related to undefined variables in the payroll calculation.
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 fixes a potential error in the GST reporting module related to tax mapping during bill creation. Previously, an incorrect tax setting led to a database violation. Now, the system correctly uses the intended tax rate, ensuring accurate reporting and preventing data inconsistencies.
Original PR description
Before this PR: During chart installation, the template sets `sgst_purchase_5` as the default purchase tax, which becomes the default supplier tax (supplier_taxes_id) for product_a. When creating the…
Before this PR: During chart installation, the template sets `sgst_purchase_5` as the default purchase tax, which becomes the default supplier tax (supplier_taxes_id) for product_a. When creating the bill with partner_b, the [tax_map](https://github.com/odoo/odoo/blob/cade6bcf0d783a8b492f5e26afbd87f2a812303e/addons/account/models/partner.py#L47) field converts product_a.supplier_taxes_id to tax_purchase_b. Since tax_purchase_b is not referenced in account_fiscal_position_tax, unlink() succeeds. After this PR: Due to changes in this [PR](https://github.com/odoo/odoo/pull/242030), the template no longer sets default purchase tax. Test common.py runs before default taxes are set by `_inverse_l10n_in_is_gst_registered`, so tax_purchase_b becomes NULL. Later, when default taxes are set, product_a gets supplier_taxes_id = sgst_purchase_5. When creating the bill, it directly uses sgst_purchase_5, which is referenced in account_fiscal_position_tax. Attempting unlink() on sgst_purchase_5 causes a foreign key violation. task-5456351
This update corrects a nightly failure related to the default time zone used for appointments. The fix involves overriding the time zone setting within testing, rather than directly asserting its value. This ensures consistent appointment scheduling across different environments and prevents disruptions.
Original PR description
**Issue:** Default tz of `'appointment.appointment_default_resource_calendar'` is not always `"Europe/Brussels"`. **Fix:** Override in test instead of asserting its value. opw-5163892 Forward-Port-Of: odoo/enterprise#105501
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 corrects an error in how the report processed data, ensuring stability and preventing unexpected errors.
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 fixes an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and reintroducing previous problems. To allow custom driver development, a checkbox was added, but this was corrected to prevent unnecessary driver downloads and ensure stability.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105531
16 changes
Enhancements to existing features
This update automatically populates employee sex and birthday information based on the NISS (Belgian National Identification Number). The 9th digit of the NISS determines sex, and the first 6 digits (YYMMDD) are used to calculate the birthday, handling century conversions automatically. This streamlines data entry and improves accuracy for Belgian HR records.
Original PR description
- Added an onchange to fill `sex` and `birthday` from `niss`. - 9th digit of NISS determines sex (even → female, odd → male). - First 6 digits of NISS (YYMMDD) determine birthday with automatic century handling. Task-5432128
This update clarifies the HR Payroll section by renaming the 'Personal Information' area to 'Statutory Information' and reorganizing the fields based on usage. This change enhances user experience and makes it easier to find relevant statutory data.
Original PR description
Purpose: - The purpose of this change is to improve clarity and usability by better reflecting the nature of statutory-related fields and organizing them in a more logical order. This PR includes: - Renamed the 'Personal Information' section to 'Statutory Information'. - Reordered fields within the Statutory Information section from most frequently used to least used for better readability and user experience. task-5452904
Resolved issues and error corrections
This update resolves an issue where users lacking specific access rights within Odoo could not submit VAT declarations through the Intervat module. By adding sudo permissions, this change ensures all users can successfully complete the submission process, regardless of their access level. This enhances user experience and compliance.
Original PR description
Add few sudo() for vat declaration, to be sure users without access rights to res.company or certificate.certificate can still make a submission. task-5470492 Forward-Port-Of: odoo/enterprise#105395 Forward-Port-Of: odoo/enterprise#103647
This update corrects an issue where FedEx labels were incorrectly displaying addresses containing special characters (like accents or non-English characters). The code has been updated to ensure all address components are converted to ASCII, resulting in accurate label formatting for all shipping addresses. This improves the reliability of shipments using FedEx.
Original PR description
Issue ----- Fedex does not handle special characters in addresses, so passing an address such as "Rue de Libération 15" will show as "Rue de Lib...ration 15" on labels. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#104979 Forward-Port-Of: odoo/enterprise#104265
This update resolves an issue where the tax code (9) was missing from Datev exports for expense payments using 19%I tax. The fix addresses a technical problem with how payment amounts are processed, ensuring accurate tax code reporting in the Datev data. This ensures consistent and compliant reporting to the accounting system.
Original PR description
Currently, when using 19%I tax in vendor bills, the tax code (9) is shown correctly in the BU-Schlüssel section of the datev export. This however is not the case for expense journal entries. Steps to reproduce: - With DE Company setup - Create an Expense as follows: - Included taxes: 19% I - Paid by: Company - Create report > Submit to Manager > Approve > Post Journal entries - Open General Ledger and export Datev Data Issue: Tax code will be missing from the exported entry. This occurs because, when processing payment move lines, amounts and accounts are aggregated, losing track of the source tax. opw-5388791 Forward-Port-Of: odoo/enterprise#105435 Forward-Port-Of: odoo/enterprise#102548
This pull request addresses critical errors identified during automated testing of the planning and timesheet grid modules. The changes fix timezone inconsistencies that were causing test failures, ensuring accurate reporting and scheduling functionality. Resolving these issues improves the reliability of the Odoo Enterprise platform.
Original PR description
Solves https://runbot.odoo.com/odoo/runbot.build.error/238011 https://runbot.odoo.com/odoo/runbot.build.error/238022 https://runbot.odoo.com/odoo/runbot.build.error/238023 https://runbot.odoo.com/odoo/runbot.build.error/238024
This update corrects a technical inconsistency where employee payroll settings were incorrectly marked as editable. The change ensures that fields marked as read-only in the version record are consistently read-only for the employee record, maintaining data integrity and preventing unintended modifications to payroll information. This resolves a prior issue flagged by automated testing.
Original PR description
There was an inconsistency on readonly for fields between version and employee. This removes "readonly=False" on employee for fields that are readonly on the version. Runbot error: 230983 Forward-Port-Of: odoo/enterprise#105414 Forward-Port-Of: odoo/enterprise#100575
This update corrects a problem where inputs weren't appearing on payslips. The fix adds the necessary domain to each relevant model, ensuring that inputs are correctly associated with payslips. This improves the functionality of the payroll system.
Original PR description
When trying to add Inputs for a payslips none appear as the domain was incorrect and only showed salary inputs for use in the employee. This is fixed in this commit by adding to the domain en each specific model. task-5486091 Forward-Port-Of: odoo/enterprise#105160 Forward-Port-Of: odoo/enterprise#103986
A bug preventing feeds from opening in the Social Twitter module has been resolved. This update addresses a technical incompatibility between the new QWeb engine feature and the existing view rendering process, ensuring feeds now open correctly. This resolves a disruption for users accessing social media feeds.
Original PR description
**How to reproduce:** - Install the social_twitter module - Enable Demo Mode - Open a Feed **Before this commit:** A traceback occurs and the feed fails to open. **Technical reason:** Introduced by this commit: https://github.com/odoo/enterprise/commit/99d583d5d6362504b4e838c7825fe9ca8d2b342c This commit introduced the parametric t-call feature for server-side QWeb engine. However, we use `ViewCompiler` to render views (here `KanbanCompiler`), which does not support parametric t-call, leading to the traceback. **After this commit:** The feed opens correctly with no traceback. Task-5707050
This update resolves a bug in the holiday scheduling Gantt chart that was introduced during a previous refactoring. The fix ensures that holiday intervals are calculated correctly, preventing inaccurate display of employee time off. This improves the reliability of the holiday calendar.
Original PR description
The bug was introduced following this refactor PR: https://github.com/odoo/odoo/pull/229706 This commit fixes the issue by computing correctly the interval with the correct type Runbot build error: https://runbot.odoo.com/odoo/runbot.build.error/238017 task-5788459
This update corrects a technical error in the l10n_au_hr_payroll module that was causing a warning message to appear incorrectly on the TFN dashboard. The fix ensures that the dashboard accurately reflects TFN status information, preventing potential confusion for payroll users. This resolves a data inconsistency.
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 prevents unnecessary email reminders for timesheet approvals. The system now only sends reminders when there are actual timesheets awaiting approval, ensuring users aren't overwhelmed with notifications. This change optimizes the approval workflow and reduces email clutter.
Original PR description
prevent cron from sending approver reminder if no timesheet assigned to approver Send the reminder email if: - there are timesheets to validate - AND if the user is set as either the manager or timesheet approver of an employee with timesheets left to be validated - OR if the said employee has no manager or timesheet approver set Task-3624610 Forward-Port-Of: odoo/enterprise#103911 Forward-Port-Of: odoo/enterprise#52355
This update fixes an issue where the 'Inventory Reason' entered during barcode inventory counts wasn't being recorded. Now, when completing an inventory count via the Barcode app, the specified reason is correctly saved and visible in the inventory history. This ensures accurate tracking of inventory adjustments.
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 potential issue where the system didn't correctly process weight readings from the scale, particularly when using the 'read_once' action. Now, the system reliably handles all weight readings, ensuring accurate data capture and reporting for IoT scale data.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`. Forward-Port-Of: odoo/enterprise#105324
This update fixes a bug where tax return names and status indicators weren't correctly translated when a new language was installed in Odoo. The solution automatically generates translations for all existing tax return names upon language installation, ensuring consistent and accurate translations 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 ensures that new partners created during shared sign requests automatically use the signer's name instead of their email address. This improves data consistency and makes it easier to identify signers within the system. It resolves an issue where new signers were created with only their email as a name.
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
13 changes
Resolved issues and error corrections
This update resolves an error that prevented the creation of new contract templates in the US payroll module. The issue stemmed from a constraint requiring a filing status, which was incorrectly applied to templates. The change ensures that the filing status is correctly set through employee data, aligning with the system's intended functionality.
Original PR description
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is…
1. Set "My US Company" state to California, 2. Go to Employees > Employees > Contract Templates, 3. Click New, 4. Fill in a name and save, 5. Invalid Operation: "The employee state filing status is empty..." A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules. This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee. We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee. The constraint will now only raise when loading a contract template on the employee or editing the field through the employee. [1] odoo/enterprise#83136 opw-5458566 Forward-Port-Of: odoo/enterprise#104990
This update corrects a technical issue that was causing an error message to appear on the TFN dashboard, specifically related to employee TFN status reporting. The fix ensures accurate warning calculations for employees applying for TFNs, improving payroll reporting reliability. This update was part of a larger upgrade process.
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 ensures that when a new partner is created during a shared sign request, the partner's name is automatically set to the signer's name, rather than relying on their email address. This improves data accuracy and consistency for shared agreements, simplifying record-keeping and reporting.
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 ensures the Helpdesk dashboard's styling is consistent with other Odoo dashboards. Specifically, the conditional formatting and border styles for the Top Customers pivot have been adjusted to match the overall design, improving the dashboard's visual appeal 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#103284 Forward-Port-Of: odoo/enterprise#103019
This update resolves an issue where extremely high IDs in Odoo's commission reports could cause errors. By using a bitwise operation instead of multiplication, the system now correctly handles large IDs, ensuring accurate report generation and preventing potential data corruption. This improves the stability and reliability of the commission reporting functionality.
Original PR description
Before this commit, we had issues on odoo.com when the ids of the account move, account move line, sale order or sle order line were too high. We would end up with ids bigger than BIGINT limit. This commit ensure it does not happen anymore by using bitwise operation on ids istead of multiplying the values. task-5423978
This update resolves an issue preventing bookings from being scheduled for the last hour of the day. The fix corrects a technical error that was incorrectly treating the end of the day as unavailable, now allowing users to book appointments until 23:00. This ensures full utilization of resource slots.
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 corrects a discrepancy in a test related to how subscription pricelists are ordered. The change ensures that pricelists are correctly prioritized based on their sequence and ID, regardless of whether a partner has a country assigned. This resolves a technical issue that didn't impact business operations.
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 resolves a test failure in the web_studio module caused by a missing dependency. The test was incorrectly checking for models that weren't part of the installed modules, specifically due to the `account_edi` module. The fix ensures the test accurately reflects the installed modules and handles missing dependencies gracefully.
Original PR description
`RELATED_MODELS_TO_EXCLUDE` contains `account.edi.document`, which is installed by `account_edi`, which is neither in the `needed_modules` set nor a dependency of any of them. Therefore the test can fail because `account_edi` is not installed even though every module in the set is. Improve the test by checking that the models or fields we're checking for actually belong to the modules we've listed. Also add the missing module in the list. Forward-Port-Of: odoo/enterprise#105408 Forward-Port-Of: odoo/enterprise#104879
This update fixes a potential issue where applicants could incorrectly reopen expired or fully-signed job offers. The change prevents access to these offers, ensuring data integrity and preventing applicants from attempting to re-sign outdated offers. This improves the overall offer management process.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#103734 Forward-Port-Of: odoo/enterprise#101834
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 corrects an error in how the report processed data, ensuring stability and reliable report generation for all 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 resolves an issue where outdated sign requests were incorrectly sending notifications to users with mismatched email addresses. The fix ensures that 'next documents to be signed' are only sent to signees with verified email contacts, improving the accuracy and reliability of the sign request process. This prevents unnecessary notifications and streamlines communication.
Original PR description
This commits fix the problem where the `signer_email` field of old sign items don't have a value defined then showed up as "next documents to be signed" for other users, even when the email doesn't match. task-5487349
This update resolves an issue where duplicate order warnings appeared when upselling subscriptions. The change specifically excludes upsell quotes from the duplicate order check, ensuring that these quotes are correctly processed without unnecessary alerts. This improves the user experience and prevents potential disruptions to the sales workflow.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Upsell the subscription to generate a upsell quote (state '7_upsell'). Issue: A duplicate order warning is displayed when upsell a subscription Solution: Exclude upsell quotes (`subscription_state == '7_upsell'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening upsell quotes. taskid-5438769
This update fixes an issue where applicant stage changes weren't correctly displayed in the recruitment reports module. The fix ensures that stage change messages appear with the correct 'Stage changed' label and uses the accurate stage name 'Qualification' instead of 'Initial Qualification'.
Original PR description
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't…
…records in hr_recruitment_reports demo data Steps to reproduce: 1. Load demo data for hr_recruitment_reports module 2. Check applicant records in chatter 3. Observe that stage change messages don't show "Stage changed" label 4. Review mail.tracking.value records for applicant stage changes 5. Observe incorrect stage name "Initial Qualification" instead of "Qualification" Bug cause: mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications. Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1). Solution: - Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions - This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label - Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification" - Ensures consistency with actual stage names and proper display in applicant chatter history Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml Task Id:5454691
9 changes
Resolved issues and error corrections
This update fixes an issue where the tour pointer was appearing in unwanted locations, like above dialogs, creating a cluttered user experience. Now, the pointer is hidden when it's not directly linked to the active element, resulting in a cleaner and more focused tour experience.
Original PR description
POC for task-5490670 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 error in the Time Off Balance report that was incorrectly calculating remaining leave days. The report previously aggregated allocations across different periods, leading to inaccurate balances. The fix ensures allocations are correctly deducted only when taken within the same period, improving report accuracy.
Original PR description
The balance report aggregates allocations regardless of the period in which they occur resulting in wrong information when an employee has two allocations in different periods and a filter is used in the report Steps to reproduce: 1. Install Time Off app 2. Open Time Off app and go to Management > Allocations 3. Create a new allocation of 100 days for employee "Mitchell Admin" of time off type "Paid Time Off" with a validity period from 01/01/2027 to 31/12/2027 and approve it 4. Go to Reporting > Balance 5. The number of days left for "Mitchell Admin" for "Paid Time Off" is 120 days even though the default filter is on the period of 2026 Solution: Subtract leaves taken from allocations only if they take place in the same period opw-5156142
This update prevents the deletion of attachments from email templates when removed from the mail composer. Previously, removing an attachment resulted in it being permanently lost, impacting future email communications. The fix ensures attachments remain associated with their templates, maintaining data integrity.
Original PR description
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by…
**Step to reproduce:** 1. Install `sale_management` 2. Open any email template (e.g., Sale: Order Confirmation). 3. Add an attachment to it 4. Create a Sale Order, confirm it, and click "Send by Email". 5. In the mail composer, remove the template attachment **Issue:** - The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails. **Cause:** - The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment. **Solution:** 1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server. 2. In `onFileRemove`, check the `res_model` of the attachment. 3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink) and only remove it from the composer view. opw-5163679
This update corrects a bug in the automatic currency rate system. The BNB now provides exchange rates in EUR, and this change ensures that companies using EUR as their main currency can correctly sync exchange rates. Companies using BGN will also experience the same error, as expected.
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 prevents users from selecting payment method lines from archived journals when creating or editing contacts. Previously, users could inadvertently use outdated payment methods. Now, archiving a journal automatically removes it from the selectable options, simplifying journal management and preventing data inconsistencies.
Original PR description
**Description of the issue/feature this PR addresses:** When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead…
**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.
**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.
**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.
https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a
OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the IoT Box was incorrectly downloading standard drivers, leading to potential conflicts and outdated versions. To allow custom driver development, a checkbox was added, but this caused unnecessary duplication and the risk of reintroducing previous bugs. Now, the system avoids downloading standard drivers to ensure stability.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones. Forward-Port-Of: odoo/enterprise#105531
This update fixes an issue where the product quantity and unit of measure fields on the MRP production kanban cards would shrink and become unreadable when product names were long. The changes ensure these fields remain consistently sized regardless of product name length, improving readability and usability.
Original PR description
Description of the issue/feature this PR addresses: On MRP production kanban, if the name of the product is too long, `product_qty` and `product_uom_id` fields on the card shrink and become unreadable. This adds proper classes to keep those fields from shrinking no matter how long product's name is. Current behavior before PR: <img width="1561" height="303" alt="image" src="https://github.com/user-attachments/assets/08e299be-c6e2-4241-b289-aaa2fab9a94f" /> Desired behavior after PR is merged: - The size of the product's name should be fine no matter how long the name of the product is. - The `product_qty` and `product_uom_id` should not shrink if the name of the product is long. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug that occurred when scheduling repair orders without a product assigned to a move line. Specifically, updating the scheduled date triggered an error related to unit of measure calculations. This fix ensures repair scheduling functions correctly, preventing disruptions to the repair workflow.
Original PR description
An error occurs when the product is not set in the repair move line, and the Scheduled Date is being updated. **Steps to Reproduce:** - Install the **Repairs** module. - Create a new **Repair Orders**. - Add a product and confirm the repair. - In the **Parts** tab, **add a new line** and change the **demanded** quantity without selecting a product. - Update the **Scheduled Date**. **Error:** `AssertionError: precision_rounding must be positive, got 0.0` `ValueError: Expected singleton: uom.uom()` (v19.0) When the move line has no `product_id`, its Unit of Measure (uom_id) is also empty. Updating the scheduled date triggers a computation, which leads to the error.
This update resolves an issue where Odoo couldn't connect to printers with overly long names. The fix truncates the printer name to a maximum of 127 characters, preventing a CUPS error and ensuring reliable printer connectivity. This improves the overall usability of the printer functionality.
Original PR description
CUPS has a limit on printer names of 127 characters, which means that if a device has a very long device URI, it can exceed this limit and cause an error when we try to add it to CUPS:
```
Failed to add printer 'dnssdPhotosmart%207520%20series%20%40%20Guillaume%E2%80%99s%20MacBook%20Air%20(2)_ipp_tcplocalcups?96d0de60-096c-3d08-5e2d-893393e10c2b'
Traceback (most recent call last):
File "/home/pi/odoo/addons/iot_drivers/iot_handlers/interfaces/printer_interface_L.py", line 242, in set_up_printer_in_cups
self.conn.addPrinter(name=device['identifier'], device=device['url'], **ppdname_argument)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
cups.IPPError: (1024, 'client-error-bad-request')
```
We fix this error by truncating the identifier to 127 characters maximum.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr5 changes
Resolved issues and error corrections
This update fixes an issue where the IoT Box was incorrectly downloading standard drivers, potentially causing conflicts and reintroducing previous problems. Now, the IoT Box only downloads custom drivers enabled by a checkbox, preventing data duplication and ensuring stability.
Original PR description
The stable IoT Box uses drivers from git repository: it doesn't download them from the database as it used to do. However, sh/on premise clients might want to develop custom drivers that the IoT Box would download. For that, they have to enable a checkbox on the IoT homepage, making the IoT Box download handlers as before. The issue is it will also download standard drivers that are already present on the IoT Box: on newer databases it would simply overwrite them, but on older ones, it would duplicate as names might have changed. Also, it would introduce issues back that were already fixed. To avoid this, we avoid adding drivers from standard modules to the downloaded archive, to prevent issues with the main ones.
This update streamlines the tax prediction process within invoices by preventing unnecessary recalculations when taxes are already defined. Previously, the system would repeatedly attempt to predict taxes, leading to slower performance. This change ensures more efficient tax calculations and a smoother user experience.
Original PR description
Before this commit, the tax prediction system would unnecessarily recalculate taxes on invoice lines that already had taxes assigned. This occurred because the `_onchange_name_predictive` method calls `_predict_taxes`, which runs even when taxes are already present on the line. This creates redundant processing and potential conflicts with the separate prediction flow in `_get_edi_creation` → `_retrieve_taxes` → `_get_specific_tax` → `AccountMoveLine._predict_specific_tax`. This commit adds a check to skip prediction when taxes are already set on the invoice line, avoiding duplicate processing and ensuring consistency between the two prediction pathways. OPW-5441710
A test related to Swiss payroll processing failed due to incorrect validation rules. This fix ensures that custom validation logic for Swiss companies is applied only when appropriate, resolving the test failure and maintaining the accuracy of Swiss payroll calculations.
Original PR description
Steps to reproduce ================== - Install l10n_ch_hr_payroll_elm_transmission - Run the test test_payslip_paid_past => AssertionError: ValidationError not raised Cause of the issue ================== The swiss localization use a custom validation. It should only be applied when the company is a swiss company. runbot-116903
This update resolves a problem preventing demo data creation in the l10n_be_hr_payroll_fleet module. The module incorrectly relied on a different dependency, leading to a missing field when auto-install was disabled. The fix ensures the correct dependency is used, allowing demo data to be created without errors.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410
This update corrects a formatting issue that occurred when removing fields from view security access. Previously, text after the removed field was not preserved, leading to inconsistent view layouts. This change ensures that views remain properly formatted even after security restrictions are applied.
Original PR description
In a view, if a field is removed due to security access restrictions, the text that follows it is not preserved. This leads to inconsistencies in the view. opw-5798852